Use cases/Lending & borrower experience

Lending-finance website

Explore how synthetic prototypes, shared field contracts and independent review could reduce integration rework and expose visibility errors earlier.

Cost · elapsed time · output quality
Trace the workWorking methods, tradeoffs and evidence

Different tools.
Shared project context.

Model, harness and platform choices used in the examples.

ClaudeClaude Code
OpenAICodex CLI
GeminiGemini CLI
AndroidApp modernization

Explore the collection

Where the work changes.
How to judge the difference.

Start with the process: cost, elapsed time and output quality.
Inspect the method, tradeoffs and evidence for each case.

Now exploring: Resolve the boundaries before connecting the systems.

Process study · proposed method

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.

Proposed method · no measured savings claim

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.

Inspect the agents, competing approaches, context and review gates.

Design the work

One problem. A coordinated agent team.

Proposed task plan

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.

Orchard orchestratorScopes work · delegates · synthesizes evidence
CONTROL

Implementation lead

01
Model familyClaudeHarnessClaude Code

Create product pages and an accessible enquiry journey from approved lender content.

Bounded task assigned

Counterproposal agent

02
Model familyGPTHarnessCodex CLI

Challenge the proposed intake: minimize collected data and keep sensitive applications in an approved service.

Opposing assumption assigned

Independent reviewer

03
Model familyGeminiHarnessGemini CLI

Inspect disclosures, form behavior, data handling and secure handoff against lender-approved requirements.

Evidence criteria assigned
Shared project contract

Rules · skills · hooks · MCP configuration

Adapted to each harness
01 / 04 · Dispatch

Split the work. Preserve the question.

One objective, distinct responsibilities

Build a lender-reviewed website while challenging every transition from public information to sensitive intake.

No model invents rates, eligibility criteria, credit policy or approval decisions.
Implementation leadpage system + enquiry schema
Counterproposal agentdata-flow counterproposal + threat questions
Independent reviewerreview checklist + synthetic flow tests
Illustrative execution planAssignment Evidence Review

Model families and pairings are illustrative. Assignments here are manual examples, not measured model comparisons or automatic cost optimization.

Trellis / shared knowledge

Approved product knowledge

Lender-reviewed descriptions, disclosures and jurisdiction scope.

Data and review decisions

Field purposes, service boundaries, threat findings and accepted revisions.

BEAM / coordination

Bounded tasks, ownership notices, findings and handoffs between sessions. A queued message and a processed receipt are distinct states.

Recall → work → retain decisions

Tools / execution

Browser + accessibility toolsForm / application sandboxRepository + security checks

Access follows the configured harness, credentials and approved scope.

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."
}

The 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

Reuse accepted context.

Share source references, constraints and decisions so each worker can start from the same reviewed material. Verify it is still current.

Parallelize independent work.

Split bounded tasks only after their interfaces are clear. Include coordination and integration overhead when evaluating elapsed time.

Make review change the output.

Use a second perspective to challenge a specific risk. Preserve the finding, the correction and the evidence that the correction holds.

Your next chapter

Where does your
work repeat itself?

Bring a real task, a baseline and acceptance criteria. Evaluate the process through the work it produces.

Explore Orchard
Photography and technology credits

Photography illustrates each project context. Interface concepts use fictional brands and sample records. Technology names and marks identify the tools discussed.