Case study / 03
Building a verified multi-agent delivery platform
Turning data-platform requests into isolated, auditable delivery workflows with specialized agents, human gates, and independent verification.
- Area
- Multi-agent orchestration
- Role
- AI & Platform Consultant
System architecture
Verified agent delivery
Specialized roles exchange durable artifacts while the orchestrator enforces isolation, human decisions, and independent verification.
- 01 / IntakeRequest
- 02 / Read onlyInvestigate
- 03 / ApprovedArtifact contractHuman decisionApprove or amend
- 04 / WorktreeImplement
- 05 / ProgramAccept
- 06 / IndependentVerify
- 07 / EvidenceDraft PR
Problem
A data team handled recurring service requests that moved through investigation, code changes, environment checks, pull-request preparation, validation, and operational handoff. The process needed a reliable way to coordinate AI agents without allowing an agent to treat plausible output as completed engineering work.
My contribution
I designed and built the platform end to end, from the agent workflow and verification contracts to the Python application and browser interface. I also defined how state, human decisions, isolated workspaces, and delivery evidence move through a request.
Agent workflow
- Role separation: A read-only investigator establishes the root cause and acceptance criteria, an implementer changes the system, and an independent verifier checks actual evidence against the criteria.
- Artifact contracts: Each stage must leave structured, inspectable files. The orchestrator advances from evidence on disk instead of relying on an agent’s narrative of completion.
- Human decisions: When investigation exposes a business choice, the run pauses and records the decision before implementation continues.
- Verified delivery: A draft pull request is created only after the required artifacts exist and independent verification passes.
Platform design
Each request runs in an isolated Git worktree with its own resumable agent session. Messages sent during execution are queued as amendments, and an append-only event log reconstructs the conversation after a restart. Requests that target the same data object are serialized to avoid conflicting changes.
The application uses a ports-and-adapters structure: domain state and services remain independent of infrastructure, while adapters handle the agent process, Git, the filesystem, command-line tools, and pull requests. A Flask API and Server-Sent Events feed a lightweight JavaScript console and an operational board derived from run artifacts and repository state.
Reliability
The repository includes unit, route, and browser-level coverage plus an end-to-end smoke gate. The smoke environment uses a temporary repository and controlled substitutes for external command-line tools, then exercises the browser, API, worktree, persisted files, and cleanup path together.
Outcome
The result is a reusable local platform that turns a data request into an isolated, auditable delivery run. It coordinates specialized agents, preserves the engineer’s decisions, survives interrupted sessions, and permits a draft pull request only after artifact checks and independent verification pass.
Team credit
I delivered the solution as a consulting engagement. Client identity, business data, and internal operational details are intentionally omitted.
System materials
Stack
- Claude Code
- Python
- Flask
- JavaScript
- Server-Sent Events
- Git worktrees
- GitHub CLI
- BigQuery