Resolve the boundaries before connecting the systems.
Explore how synthetic prototypes, shared field contracts and independent review could reduce integration rework and expose visibility errors earlier.
Establish the baseline
- Approved product descriptions
- Reviewed jurisdiction-specific disclosures
- Enquiry and data-handling requirements
Evidence to retain
- Reviewed fields and role boundaries
- Synthetic workflow and failure checks
- Accepted handoff and unresolved decisions
Why work this way?
The process, and what it could improve.
Cost
Find the data boundary before connecting systems.
Prototype approved fields and role-specific views with synthetic records. Resolve disputed visibility and review rules before integration work.
- What to compare
- Implementation, model and specialist-review cost per accepted workflow, including security corrections.
- The tradeoff
- A synthetic prototype is cheaper to change, but it does not replace production security or legal review.
Find the data boundary before connecting systems.
Compare the same scope and acceptance criteria. Include setup, coordination, failed attempts and human review alongside the successful model call.
Design the work
One problem. A coordinated agent team.
A model reasons. A harness runs its agent session and tool loop. Orchard coordinates the work, context and handoffs across them.
Orchestration phase 1: Split the work. Preserve the question.
Implementation lead
01Create product pages and an accessible enquiry journey from approved lender content.
Counterproposal agent
02Challenge the proposed intake: minimize collected data and keep sensitive applications in an approved service.
Independent reviewer
03Inspect disclosures, form behavior, data handling and secure handoff against lender-approved requirements.
Rules · skills · hooks · MCP configuration
Adapted to each harnessSplit the work. Preserve the question.
One objective, distinct responsibilities
Build a lender-reviewed website while challenging every transition from public information to sensitive intake.
page system + enquiry schemadata-flow counterproposal + threat questionsreview checklist + synthetic flow testsModel families and pairings are illustrative. Assignments here are manual examples, not measured model comparisons or automatic cost optimization.
Inspect the example work orderJSON
An illustrative work-order format for this scenario. Changing an example session updates this document; no agents run from this page.
{
"example": "lending-finance-website",
"objective": "Build a lender-reviewed website while challenging every transition from public information to sensitive intake.",
"boundary": "No model invents rates, eligibility criteria, credit policy or approval decisions.",
"sessions": [
{
"role": "proposer",
"model_family": "Claude",
"harness": "Claude Code",
"task": "Create product pages and an accessible enquiry journey from approved lender content.",
"expected_artifact": "page system + enquiry schema"
},
{
"role": "challenger",
"model_family": "GPT",
"harness": "Codex CLI",
"task": "Challenge the proposed intake: minimize collected data and keep sensitive applications in an approved service.",
"expected_artifact": "data-flow counterproposal + threat questions"
},
{
"role": "reviewer",
"model_family": "Gemini",
"harness": "Gemini CLI",
"task": "Inspect disclosures, form behavior, data handling and secure handoff against lender-approved requirements.",
"expected_artifact": "review checklist + synthetic flow tests"
}
],
"project_contract": [
"Rules",
"Skills",
"Hooks",
"Tool configuration"
],
"shared_context": [
"Approved product knowledge",
"Data and review decisions"
],
"evidence_required": [
{
"label": "Copy stays within approved claims",
"evidence": "Trace product statements and disclosures back to their reviewed source."
},
{
"label": "Data collection is justified",
"evidence": "Map every field to purpose, destination, consent and retention requirements."
},
{
"label": "The boundary works",
"evidence": "Test synthetic enquiries, error handling and the secure application handoff."
}
],
"release_owner_gate": "Lender product, legal and security owners review their respective requirements before publication."
}Chapter 1: Start with approved product information.
Chapter 01 / 04
Start with approved product information.
Organize products, audience, disclosure requirements, and the enquiry journey. Identify what can be public and what belongs in a secured system.
Content agent + product and legal owners
Reviewed content map
Products + disclosures + enquiry scope + review ownersThe process principle
Move uncertainty into a reviewable prototype.
Scope of this exampleNo rates, eligibility promises, credit decisions, or approvals are generated here. Real applications need approved systems and legal, security, and lending review.
A fictional site concept, not a lender, financial offer, underwriting service, or customer result. Application security reference






