Building AI Systems That Have to Talk to Other AI Systems

Most AI systems are built as if they will run alone forever. Then six months in, someone needs them to talk to another AI system. The retrofit is harder than the original build.

This post is the design discipline for AI systems that will need to interoperate. The principles to apply during the original build so the interop work later is cheap.

Not a tutorial. A list of architectural choices that compound.

Design Choice One: Decide Now Whether Your Outputs Are Contracts or Suggestions

Every AI output is either a contract or a suggestion. The difference matters.

A contract output is one that downstream systems will treat as authoritative. If your model says the customer's company is "Acme Industries," another system uses that string to look up records, route messages, draft emails. Errors propagate as facts.

A suggestion output is one that requires human review or downstream verification before action. If your model says "this customer might be at Acme Industries," another system flags it for confirmation before using it.

Both are valid. They require different contracts. Contract outputs need confidence scores, required claim declarations, and explicit fidelity expectations. Suggestion outputs need explicit uncertainty markers and downstream-routing rules that prevent the suggestion from being treated as a fact.

Decide which kind of output your system produces during the design phase. Building both into the same output stream later requires unwinding architectural decisions that have already locked in.

Design Choice Two: Versioning Is Not Optional

Every AI system goes through model updates, prompt changes, fine-tuning runs, retraining cycles. Each change has the potential to alter output behavior in ways that look minor but break downstream consumers.

Three versioning layers to commit to before the first deployment.

Model version. The specific model file, weights, or base model. When this changes, downstream consumers need to know.

Prompt version. The specific prompt template producing the output. When this changes, the output distribution shifts even with the same model.

Schema version. The structure of the output. When fields are added, removed, or repurposed, downstream parsers need to know.

All three versions belong inside every output. Receiving systems can then decide what to do when versions change. Strict mode (reject anything with a version they have not tested against). Permissive mode (warn but consume). Adaptive mode (run compatibility logic against known version pairs).

Without version metadata, none of these modes are possible. The receiving system has no way to know what changed.

Design Choice Three: Make Confidence Explicit

Many AI systems produce outputs without confidence scores. The justification lands on "the model does not produce native confidence" or "confidence is hard to calibrate." Both reasons are real. Neither is a license to skip the layer.

If your model does not produce native confidence, derive it. Use response length, entropy of the next-token distribution, agreement across multiple completions, or any heuristic that gives downstream systems a signal about how certain the output is. A derived confidence is better than no confidence.

If calibrating confidence is hard, do not calibrate it for absolute interpretation. Use it for relative ordering. A confidence of 0.9 on one output should be more reliable than a confidence of 0.4 on another, even if the absolute numbers do not mean "90% likely correct." Relative confidence is still actionable.

Downstream systems can use confidence for routing, thresholding, escalation, and audit. None of those uses require perfect calibration. They all require the layer to exist.

Design Choice Four: Lineage From Day One

Every output your system produces should record where it came from. Not as a logging concern. As a payload concern.

The output payload should include or reference the inputs that produced it. The input identifiers, the timestamps, the systems that contributed. When the output later turns out to be wrong, the lineage is the diagnostic path.

Lineage as a logging concern is an afterthought. Logs get rotated. Retention policies expire. Different systems log to different stores in different formats. By the time someone needs the lineage, it is fragmented across an infrastructure surface that no single team owns.

Lineage as a payload concern is permanent. It travels with the data. It survives infrastructure changes. It is queryable wherever the data is stored.

The cost of adding lineage to the payload is modest. The cost of retrofitting it after the failures surface is significant.

Design Choice Five: Required Claims Are a Producer Responsibility

The producing system knows which fields are load-bearing for downstream consumers. Most producing systems do not declare this knowledge anywhere consumable.

If your model produces a payload where "company_name" is load-bearing and "founding_year" is decorative, that distinction lives in the head of the engineer who built the producer. Downstream systems have no way to know which fields they must preserve when transforming the payload.

Declaring required claims is a producer responsibility. The producing system specifies which fields must survive any downstream transformation. The receiving system honors the specification or it operates against the contract.

This is a discipline, not a feature. Producing systems are accountable for declaring what matters. Receiving systems are accountable for preserving what was declared.

Design Choice Six: Treat Every Output as an Envelope, Not a Payload

Most AI systems produce payloads. Strings. JSON objects. Structured records. The output is the data.

AI systems designed for interoperability produce envelopes. The envelope wraps the data with the contract metadata. The data is still inside. The envelope adds version, semantics, lineage, required claims, and verification.

This is the architectural inversion. The thing your system produces is not the data. It is the envelope that contains the data and the contract.

Downstream consumers can extract the data when they need just the data. They can also consult the envelope when they need to validate, verify, or trace. The producing system has done both jobs. The receiving system has the choice.

The Honest Cost

I want to name this directly because it is the reason most teams do not build for interoperability.

Adding contract layers to an AI system costs engineering time. Three to five additional weeks of build during initial development. Ongoing maintenance of versioning, lineage, and required claims as the system evolves. Discipline of treating outputs as envelopes rather than payloads.

The benefit shows up later. When the second AI system needs to consume the first one's outputs, the integration is straightforward because the contract layer is already there. When the third system needs to consume the second one's outputs, the lineage chain is already established. When something breaks, the diagnostic path is already encoded.

Without the contract layer, every integration is bespoke. Every failure is a new investigation. Every change cascades through every consumer in ways nobody planned for.

The cost of the contract layer is paid up front. The cost of the absent contract layer is paid later, in pieces, by whoever happens to be on call when each failure surfaces.

Where to Start

If you are building an AI system today, three actions to commit to before the first production deployment.

One. Decide whether outputs are contracts or suggestions. Document the decision. Build the output structure around it.

Two. Add version metadata to every output. Model version, prompt version, schema version. Make them queryable.

Three. Add lineage to every output. Reference the inputs that produced it. Make the chain extensible.

The full CORD envelope structure has more layers (semantics, required claims, verification). Three actions above produce a partial envelope. Partial is enough to start. The remaining layers can be added incrementally as the pipeline grows.

The next post moves to the executive case. How a CTO or VP of engineering frames the contract layer to leadership. Why it is infrastructure work, not feature work. What it returns over the lifetime of the AI program.

Structure before tools. Strategy before speed. Systems before scale.

The AI Operator Framework is the methodology for designing, governing, and scaling AI operations inside a business, including the data and citation fidelity layers most companies skip. Explore the full framework at JamilAshkar.com/framework. Start with the free course at JamilAshkar.com/course.