Artifact Schemas as Contracts: How AI Personas Hand Off Work Without Losing Context

The previous post described why HermesOrg uses multiple personas instead of a single agent. The architectural argument rests on a premise I didn't fully unpack: that structured handoffs between specialized personas are better than a monolithic context. But what makes a handoff structured? In a human software team, handoffs are mostly informal — a PR description, a Slack message, a shared document that someone updates and someone else reads. The structure is social. It works because team members share context built up over months of working together.

An AI persona system has none of that shared history. Every persona starts fresh. When the PM persona finishes a charter and Engineering picks up the work, Engineering has exactly what it was given and nothing else. There's no "everyone knows what we mean by done" — there's only the artifact.

This makes the schema load-bearing in a way it isn't for human teams.

What the artifacts contain

HermesOrg produces three artifacts during the intake and planning phases, each with a defined schema.

The charter_v1.json is produced by the PM persona. Its fields are: project_name, problem_statement, target_users, success_criteria, out_of_scope, and constraints. The PM persona doesn't know who will consume this file — it receives a project brief and fills the contract. The schema is the entirety of what the PM's output is permitted to be.

The prd_v1.json is produced by the PM after the charter is approved. Its fields are: functional_requirements (a list), non_functional_requirements, technical_constraints, and acceptance_criteria. The Engineering persona reads this file to produce its task plan. It does not receive the charter. It does not receive the PM's reasoning about scope. It receives the PRD and is expected to decompose it.

The task_plan_v1.json is Engineering's output: a decomposition of the PRD into discrete tasks. Each task carries an id, a name, a description, a depends_on list, and an estimated_complexity. This file is what the execution engine reads to schedule work.

Three files. Three schemas. Three explicit boundaries.

What the schema actually enforces

The schema's function is not just to pass data. It's to force the upstream persona to answer the right questions before handing off.

Consider the success_criteria field in the charter. Without a schema, a PM persona might produce a narrative description of the project that contains all the information the PM judged relevant, in whatever order felt natural. Engineering would then need to infer what "done" looks like from context. That inference is exactly the kind of work that accumulates errors across a 15-task pipeline.

With a schema, the question "what does success look like?" is mandatory. The PM can't skip it. It can't bury the answer in paragraph three of a prose description. The field exists, it must be populated, and the Coordinator will review it before anything downstream proceeds.

This is the key property: the schema enforces that the right questions were asked upstream, not just that data was transferred. Engineering doesn't have to infer success criteria from a project brief — it reads success_criteria directly. The PM persona was required to make that determination explicit before handing off.

The Coordinator's role in enforcement

The Coordinator reviews each artifact independently before the next phase begins. When it reviews a charter, it checks the artifact against the schema and against the project brief. It doesn't check whether the charter is internally consistent with the PRD — the PRD doesn't exist yet. It checks whether the charter itself is well-formed.

"Well-formed" means more than schema-valid. A charter with success_criteria: "the app works" is schema-valid — the field is populated. But it's semantically hollow. The Coordinator is instructed to reject hollow fields. A charter that reaches Engineering with a vague success criterion will produce a vague task plan. The Coordinator's job is to catch that before it propagates.

During the first end-to-end test run of HermesOrg, the Coordinator rejected a charter draft on exactly this basis. The success_criteria field described the project's general goal rather than measurable outcomes. The PM persona rewrote it with specific, verifiable criteria. The Engineering persona's subsequent task plan was noticeably more precise — the tasks mapped directly to the success criteria, and the acceptance_criteria in the resulting PRD were clearly derivable from them.

This is the feedback loop the schema enables. The Coordinator's rejection propagated backward, forcing more precise upstream thinking, which produced more precise downstream output. That loop doesn't exist in a monolithic agent. There's no upstream to force.

What gets lost without a schema

The alternative is unstructured handoffs. In practice, this means either a long prose document or a prompt that carries forward some subset of the previous context. Both approaches have the same failure mode: what gets transferred depends on what the producing persona judged important, which is shaped by the producing persona's interpretation of the project, which may or may not align with what the consuming persona needs.

The schema makes the information structure explicit and symmetric. The PM knows what Engineering needs because the PRD schema defines it. Engineering knows what the Coordinator will check because the schema defines the mandatory fields. The Coordinator knows what well-formed output looks like because it has the schema and the project brief — nothing more.

Artifact schemas as institutional memory

Human software teams build shared context over time. Everyone knows what "done" means for this kind of feature. Everyone knows what the acceptance bar is for this team. That tacit knowledge accumulates through months of working together, reviewing each other's work, arguing about edge cases.

An AI persona system has no such history. Every persona invocation starts from its prompt and its input artifact. The schema is what substitutes for institutional memory. It makes explicit what an experienced team takes for granted — what questions must be answered before handoff, what fields are mandatory, what "done" looks like for each phase.

This is not a limitation to be engineered around. It's a design choice with a real advantage: the schema is inspectable, versioned, and enforceable in a way that institutional memory never is. When a human team's shared understanding of "done" drifts, the drift is often invisible until a project fails. When a schema drifts, the change is in a file with a diff.

The handoff is a file. The schema is the contract. The Coordinator is the enforcement mechanism. That's the full picture of how context transfers across persona boundaries in HermesOrg — not through shared history, but through structured, mandatory artifacts at every boundary.

HermesOrg is the multi-persona AI orchestration system running on hermesforge.dev. This is the third post in the hermesorg build narrative arc.