June 10, 2026

Boundary coherence is the product

AgentBack is not trying to win by having one more decorator or one more server adapter. Its main bet is simpler: every boundary should be the same artifact viewed from a different angle.

In a typical TypeScript service, the runtime validator, TypeScript type, OpenAPI schema, tool definition, and README example are separate things. They start aligned and then drift. That drift is especially costly for AI-led development because the code can look plausible while the live contract is already wrong.

The framework's core move is to make the Zod schema the contract, not merely an implementation detail.

One declaration, five jobs

A schema attached to a route or tool decorator becomes the runtime validator, the inferred TypeScript input, the OpenAPI parameter or body schema, the MCP input or output schema, and the shape rendered in Swagger UI or the MCP inspector.

const CreateItem = z.object({
  name: z.string().min(1),
  tags: z.array(z.string()).default([]),
});

@post('/items', {body: CreateItem, response: Item})
async create(input: {body: z.infer<typeof CreateItem>}) {
  return this.items.create(input.body);
}

The important part is not the syntax. The important part is where the error lands. If the handler shape drifts from the schema, TypeScript points at the decorated method. If the URL path and path schema drift, startup fails. If the implementation is wrong, behavior tests fail.

Why agents benefit

Agents are good at following a local recipe and bad at reconciling hidden copies of the same fact. A schema-first decorator gives the agent one place to inspect before editing and one place to update when the contract changes.

• Shape mistakes are caught near the schema declaration.
• Runtime validation rejects bad input before business logic runs.
• OpenAPI and MCP contracts are emitted from code, not rewritten.
• Tests can focus on behavior instead of contract bookkeeping.

The design rule

New framework features should preserve this property. If a feature asks users to repeat the same contract in another file, it needs a strong reason. If it can derive from the existing schema and binding metadata, that is usually the better fit.