In a Farna Control pipeline, an agent can declare two typed contracts: an input schema and an output schema. The input schema defines what the agent receives; the output schema defines what it must produce. Together they make Farna Control agent-agnostic: any agent that respects the contract can be plugged into any pipeline node.

An agent that generates deployment configs shows why. It receives a prompt, produces a YAML config, and the next step applies it to production. Without schemas, malformed YAML, a missing required field, or a bad value surfaces minutes later, after the config is applied, and the rollback takes an hour. The damage comes from the mistake passing through two pipeline steps before anyone noticed. An input schema catches the malformed prompt before the agent starts, and an output schema catches the bad config before the deployment step.

In short

What it does: where a schema is declared, it validates agent input before execution and output after execution, catching malformed or dangerous data at that boundary.
When you would use it: any agent that produces structured output - PR descriptions, config files, JSON payloads, test fixtures, YAML.
When you would not: simple text classification or summarization where a regex gate or eval score (quality rubric) suffices, or simple triggers whose payload the trigger's own guardrails already validate.

How it works

Input schema

The input schema defines what data you send to the agent at dispatch: the trigger context (repository, branch, PR number, ticket ID), the prompt, and relevant pipeline state. It is validated before the agent receives it, so the agent never handles malformed input and an invalid input is caught before wasting an expensive invocation.

Output schema

The output schema defines what the agent must produce: a pull request diff, a PR description, a test file, a documentation update, or any other structured output. It is validated after the agent finishes, before it reaches any gate or human reviewer. A mismatch pauses the run and records the validation failure; the agent never skips the schema check.

Schema versioning

Schemas are versioned with semver. Updating a schema leaves existing runs unaffected because they reference the schema version pinned in their snapshot, so you can evolve contracts without breaking in-flight pipelines. A major bump means the contract changed in a breaking way: agents configured for the old schema are not dispatched until updated. A minor bump means the contract expanded with new optional fields, and existing agents continue to work.

Schema inference

Farna Control can generate schema drafts from connector data. When you connect a GitHub repository, Farna Control can inspect the repository structure and generate a schema for the types of changes the agent is expected to make. This accelerates initial setup rather than replacing hand-authored schemas.

Journey example: before and after

Before

A team led by Sam runs an agent to generate PR descriptions. Half are missing the "Testing" section, so the team reviews each one manually and adds it, costing 10 minutes per PR and frustrating reviewers.

After

Sam adds an output schema that requires the "Testing" section. The agent now always includes it, and the schema gate catches the 5% of runs where it still tries to omit it, pausing for a correction instead of shipping an incomplete description. The team stops reviewing for structure and starts reviewing for content.

Where it fits in a pipeline

Where declared, schemas sit at the input and output boundaries of an agent node, the first line of defense before gates, evals, or human review. For the governance layer that validates what the agent produces beyond structure, see Feature Spotlight: How HITL gates stop bad agent output before it ships. For the principles behind this approach, see the principles of Farna Control.

Go deeper

Read the Schemas docs for the full schema configuration, or the related docs on agents and feedback. Take the product tour to see schemas in action, or use the contact page to talk to us about adding schemas to your pipeline.