Audio brief · 2 min
Case Study · AI-assisted data operations

Imports that negotiate with the sender's AI agent

A multi-office US property valuation firm needed data from every regional office in one central database, without forcing a template on anyone. The offices now extract that data with an agentic workspace First Line deployed on every appraiser's desk and trained them on, so the import service was built to answer that agent the same way: machine-actionable findings, including a verdict on whose problem it is. Built by a Pit Wall of two, an AI Product and a Forward Deployed Engineer, with a Silicon Pit Crew of AI agents writing the code instead of a conventional human Pit Crew. Against a conventional team that already works with AI tools, the build took 7.1 times less human effort and cost 2.9 times less to produce, in four months against an estimated four and a half.

The challenge

Two ways to lose, before you start

Regional offices hold rich property data in heterogeneous spreadsheets extracted from appraisal documents. Consolidating it centrally usually collapses into one of two failures. Mandate a rigid template on every office and adoption dies, because the template never fits how any given office actually works. Hand-map every variant centrally and the cost explodes, while the database schema slowly fills with the quirks of each source.

The source material is not a clean export. It is PDFs, brochures and spreadsheets, up to ten documents per appraisal and thirty to a hundred pages each. Every office has its own format.

A third pressure made the usual answers worse: the offices were moving to an agentic workspace that First Line rolled out to every appraiser. The sender was no longer reliably a person reading an error report.

The solution

Standardize the contract, not the people

The import service classifies content instead of matching templates. Sheet names, column headers, and value formats may vary freely; a layered engine of deterministic rules, a domain vocabulary, and a scoped AI fallback works out what the data means.

A stable intermediate format acts as the firewall. Readers absorb source-format drift on one side, and the database writer consumes only the strictly typed intermediate on the other, so source variation and schema evolution stop being each other's problem. The writer never re-parses a string; it dispatches on declared types.

Nothing unidentified reaches the database. An integrity gate validates every import before the write, unresolvable content is quarantined rather than silently guessed, every value carries cell-level provenance, and every import carries an attested record of data origin, which matters when licensed third-party market data is involved.

The sending agent is an off-the-shelf agentic workspace on the appraiser's own desk, connected to the platform over MCP. It extracts the data from the documents, checks and enriches it locally, then imports it through the MCP interface. First Line deployed the workspace on every appraiser's desk and trained the offices to use it. This is a new way in, next to the classic web interface, not a replacement for it.

The differentiator

When the sender is an agent, the error report should be too

The service exposes an agent-facing MCP interface, so the appraiser's agent can upload, track status, read findings, and resubmit end to end. Each finding carries a location, evidence, a concrete suggested action, and a routing verdict.

That verdict is the design decision that does the work. The system can say, in machine-readable form, not your problem, do not re-extract, our importer mis-bound this column. Classic integrations cannot say that; they can only insist the file is wrong. The result is a closed correction loop: a resubmission declares which attempt it supersedes, the service diffs the attempts and reports convergence, or flags a regression when a re-extraction has lost fields the previous one had. Most issues resolve agent to agent in a round or two.

Humans still get a human artifact. The same findings render as the office's own workbook, returned with per-cell comments and a linked issue index. One taxonomy, three renderings: for machines, for agents, and for people.

The team

Two people and the agent

The platform is built by a Pit Wall of two: an AI Product role and a Forward Deployed Engineer. There is a Pit Crew, but not a conventional one made of people: it is a Silicon Pit Crew of AI agents. The Forward Deployed Engineer who works out the client's intent is also the one who implements against it, with the Silicon Software Engineer, the AI agent, writing the code.

AI Product talks to the client twice a week, writes the specification and accepts the result. There is no separate quality engineer. The quality gate is split between the two, so nobody queues behind a third person.

That is the compression the framework predicts, in its sharpest form. The conventional staffing for a system of this shape, a business analyst mapping every source format, developers building importers, and QA validating the results, collapses into two people who never hand work across a boundary. The specification does not have to survive a translation step, because the person who wrote it is the person who builds against it.

The engineer's job changed with it. The Forward Deployed Engineer writes very little of the code. The role builds the machinery the Silicon Pit Crew runs on, so that agents can produce the whole backlog end to end. When the swarm blocks, the fix goes into the machinery, not the output.

There are no sprints. The team works week to week, ships an update into the application every week and sends the client a digest.

The numbers

Seven times less effort, in about the same calendar time

The two people logged 92 person-days over four months: 72 from the Forward Deployed Engineer and 20 from AI Product. That is the only measured figure in the comparison.

The baselines are estimates for the same scope. By our own staffing estimate, a conventional team here would be eight people. With AI tools it would need about 655 person-days and 4.5 months. Without AI, about 1,080 person-days and 7.5 months. The 655 applies the 65% delivery gain measured on this client's core platform team to the 1,080.

Against the team with AI tools, human effort is 7.1 times lower. The two people cost about 2.5 times more per day, so the cost of production is 2.9 times lower. Against the team without AI, the same arithmetic gives 11.7 times less effort and 4.7 times lower cost. This is cost of production, not price to the client.

The calendar barely moved: four months against an estimated 4.5 for the team with AI tools. Only against the team without AI is it faster, four months against 7.5, or 1.9 times. A conventional team buys speed with more people in parallel, so the RACE triangle shows the gain in effort and cost, not in duration. Quality held, because quality is never a lever. The client took the gain as price and speed: a lower price than a conventional team would cost, and delivery in four months against an estimated 7.5 for a team without AI.

The calendar is bound by the client, not by the build. It depends on how fast requirements arrive and get approved, and on how long the client's user acceptance testing takes at the end.

The RACE pattern

The same discipline, pointed inside the product

RACE Programming is usually described as how a team builds. This engagement is what happens when the same stance is built into the thing the team ships, because here the AI agent is not only the builder, it is also a participant in the running system.

  • The Silicon Software Engineer executes, humans keep judgment. In RACE the agent writes the code and a person owns acceptance. Here the sending agent fixes and resubmits data, while certifying data origin and clearing warnings stay human. Same boundary, moved from the delivery team into the product.
  • A specification precise enough for a machine. The Executable User Story exists because an agent cannot build from prose it has to reinterpret. The import findings are the same idea aimed outward: location, evidence, suggested action, and a routing verdict, so the receiving agent can act without a human translating for it.
  • Gates, not review by eyeball. RACE puts a four-gate Definition of Done in front of production. This platform puts an integrity gate in front of the database: nothing unidentified is written, and unresolvable content is quarantined rather than guessed.
  • Everything as Code. Rules, vocabulary, and provenance are machine-readable state rather than knowledge held by whoever ran the last import, which is what makes the pipeline deterministic and auditable.
The guardrails

Capability, never authority

  • An agent can fix and resubmit files. It cannot certify data origin on a human's behalf, and there is deliberately no interface through which it could.
  • No agent bypasses classification or the integrity gate, and imports carrying warnings still stop for human review.
  • Feedback text is composed from templates and structural fields only. Raw cell content, which an attacker can control, is never interpolated into agent instructions.
  • The pipeline is deterministic: the same input against the same rules produces an identical result.
The limits

What still needed a person

One thing did not go to the swarm: changing which fields are required took a person. A required field is either on or off and cannot be softened, so the change needed a negotiation with the client and a change request.

The result

In production, with the humans at two points

The platform runs in production for the firm's regional offices. The domain vocabulary spans roughly nine hundred header aliases and hundreds of normalized enum values, and the system is covered by several hundred tests including a multi-workbook regression corpus. Offices send what they already have; the humans touch the loop at exactly two points, certifying data origin and reviewing warnings.

Client identity withheld. Delivery facts are as reported by the engineering team. The same stance shows up across RACE Programming engagements: agents get capability, humans keep authority, and every automated action is scoped, verified, and auditable.

More case studies → · Read the framework →

FAQ

Frequently asked questions

What was delivered in this engagement?
A production data-import platform for a multi-office US property valuation firm consolidating property, sales, lease, and financial data from its regional offices. Instead of mandating a rigid spreadsheet template, the service classifies content: sheet names, column headers, and value formats vary freely, and a layered engine of rules, domain vocabulary, and scoped AI fallback works out what the data means. Every import passes an integrity gate before anything is written, and every value carries cell-level provenance.
What makes this an agent-to-agent system?
The regional offices extract their data with an agentic workspace First Line deployed and trained them on, so the import service exposes an agent-facing MCP interface. The sending agent uploads, tracks status, reads findings, and resubmits without a human in the loop. Findings are machine-actionable rather than a human error report: each issue carries a location, evidence, a concrete suggested action, and a routing verdict that says whose problem it is.
Why does it matter that the system can blame itself?
Because the alternative wastes the sender. Classic integrations only ever say "your file is wrong." This service can return a first-class, machine-readable answer that means "do not re-extract, our importer mis-bound this column." Without that verdict, the sending agent burns rounds correcting data that was already clean, and each of those rounds becomes a human support ticket.
How much faster and cheaper was delivery?
Mostly cheaper, not faster. Against a conventional team that already uses AI tools, the build took 7.1 times less human effort and cost 2.9 times less to produce, in four months against an estimated 4.5. Against a team without AI, effort is 11.7 times lower, cost 4.7 times lower and the calendar 1.9 times shorter. The client took the gain as price and speed: a lower price than a conventional team, and four months against 7.5 for a team without AI. The calendar is bound by the client's requirement approvals and acceptance testing, so in the RACE triangle the gain shows up as effort and cost, with quality held. The structural reason is the team shape, a Pit Wall of two with the agent executing, where the conventional staffing of business analyst, developers, and QA would have carried hand-off cost at every boundary.
How does this relate to RACE Programming?
Two ways. In delivery, the platform is built by a Pit Wall of two, an AI Product role and a Forward Deployed Engineer who both works out the client intent and implements against it, with a Silicon Pit Crew of AI agents writing the code instead of a conventional human Pit Crew. That is team compression in its sharpest form: the conventional staffing of business analyst, developers, and QA collapses into two people with no hand-off boundary. In architecture, the same stance is applied inside the product, because the AI agent is a participant in the running system too. The sending agent fixes and resubmits data while certifying data origin stays human; findings are specified for a machine the way an Executable User Story is; an integrity gate guards the database the way the Definition of Done guards a release; and rules, vocabulary, and provenance are machine-readable state rather than tribal knowledge.
What stops an AI agent from corrupting the database?
Agents get capability, not authority. An agent can fix and resubmit files, but it cannot certify data origin on a human's behalf, cannot bypass classification or the integrity gate, and imports carrying warnings still stop for human review. Unresolvable content is quarantined rather than guessed into production, and feedback text is composed from templates and structural fields only, so attacker-controllable cell content is never interpolated into agent instructions.