How input/output schema works with external agents

Every agent in a Modulo pipeline has two typed contracts: an input schema and an output schema. These schemas define exactly what the agent receives and what it must produce. They are the mechanism that makes Modulo agent-agnostic - any agent that respects the contract can be plugged into any pipeline node.

Input schema

The input schema defines what data the agent receives when it is dispatched. This includes the trigger context (repository, branch, PR number, ticket ID), the agent's prompt, and any relevant pipeline state. The input is validated against the schema before the agent receives it, so the agent never has to handle malformed or unexpected input.

This validation is important because agents are expensive to run. If the input is invalid, better to catch it before the agent starts than to let it fail mid-execution and waste the invocation.

Output schema

The output schema defines what the agent must produce. This could be a pull request diff, a PR description, a test file, a documentation update, or any other structured output. The output is validated against the schema after the agent finishes, before it reaches any gate or human reviewer.

If the output does not match the schema, the run pauses and the validation failure is recorded. The agent never gets to skip the schema check - it is enforced before anything else happens.

Schema versioning

Schemas are versioned with semver. When you update a schema, existing runs are unaffected because they reference the schema version pinned in their snapshot. This means you can evolve your contracts without breaking in-flight pipelines.

A major version bump means the contract changed in a breaking way - agents configured for the old schema will not be dispatched until they are updated. A minor version bump means the contract expanded (new optional fields) - existing agents continue to work.

Schema inference

Modulo can generate schema drafts from connector data. When you connect a GitHub repository, Modulo can inspect the repository structure and generate a schema for the types of changes the agent is expected to make. This is not a replacement for hand-authored schemas, but it accelerates the initial setup.

What this enables

Because every agent boundary is a typed contract, you can:

• Swap the agent runtime without changing the pipeline (Claude Code, Codex, Cursor - any agent that respects the contract)
• Validate agent output before it reaches any downstream system
• Evolve contracts independently of the agents that implement them
• Audit exactly what crossed each boundary in every run

The principle behind this: schema seams - every boundary is a typed contract, so an agent cannot pass garbage downstream without a record of it.