What must exist around a model for its intelligence to become reliable, accountable work?

A model can write a plan. It cannot make the plan operational.

It can recommend an action. It cannot determine by itself whether that action is authorized.

It can analyze the evidence placed before it. It cannot guarantee that the evidence is complete, current or trustworthy.

Turning an impressive answer into dependable organizational work requires something larger: an AI system.

Three disciplines sit near the center of that system: context engineering, agent orchestration and evaluation.

Context determines the reality available to the system. Orchestration determines how responsibilities are distributed. Evaluation determines whether the resulting work is acceptable.

Together, they turn model capability into system capability.

AI architecture is becoming an architecture of cognition

Traditional systems architecture organizes computation, data, applications, networks and services. AI systems still require those foundations, but they introduce another architectural problem: we must organize how the system knows, remembers, reasons, coordinates, verifies and acts.

That means designing:

  • What information reaches the model
  • Which sources should be trusted
  • What the system remembers and forgets
  • How a problem is divided into tasks
  • Where probabilistic judgment is appropriate
  • Where deterministic computation is required
  • How conclusions are evaluated
  • When the system may act
  • When it must abstain or escalate
  • How its decisions can later be reconstructed

This is more than connecting an LLM to existing software. It is the deliberate construction of the conditions under which machine intelligence operates.

Context is the system’s constructed reality

An AI system does not encounter an organization directly.

It encounters a representation assembled from instructions, retrieved documents, database records, policies, tool outputs, previous interactions and stored memories. That representation becomes the reality inside which the model reasons.

Context engineering therefore involves much more than writing better prompts or fitting additional information into a context window. It determines what the system can see, what it treats as authoritative, which relationships remain visible and what gets excluded.

Every AI system operates inside a constructed reality. Context engineering decides what that reality contains—and what it leaves out.

A powerful model working with stale, fragmented or manipulated context may be less useful than a smaller model receiving carefully selected and well-structured evidence.

Recent research illustrates how deep this problem goes.

The authors of RippleMem argue that long-term agent memory is not simply a storage problem. Relevant evidence may be scattered across many previous interactions. Retrieving isolated fragments can leave an agent with an incomplete picture, even when the necessary information technically exists in memory.

Their system starts with relevant memory anchors and follows semantic and structural relationships to recover supporting evidence. The important idea is the shift from treating memory as a collection of searchable fragments toward treating it as a network of events, relationships and evidence.

Context can also become an attack surface. RAGSieve examines knowledge poisoning in retrieval-augmented systems: malicious documents are introduced into a corpus so that later queries retrieve attacker-chosen claims as evidence. In the authors’ experiments, combining detection during corpus ingestion and retrieval reduced attack success from 67.4% to 14%.

These are early research findings, not production guarantees. But they reveal an architectural truth: once external knowledge influences reasoning, the integrity of that knowledge becomes part of the security boundary.

The RAG corpus is no longer just a data source. It is part of the AI supply chain.

Orchestration is the design of responsibility

Agent orchestration is often described mechanically: one agent delegates, several agents work in parallel, and another component combines their results.

That description misses the more consequential question:

Who—or what—is responsible for discovering, deciding, verifying, acting and resolving disagreement?

A robust system may use one agent to gather evidence, another to challenge assumptions and a third to construct a recommendation. Deterministic code may perform calculations. A policy engine may authorize actions. A human may remain accountable for the final decision.

The value does not come from having more agents. It comes from creating a defensible separation of responsibilities.

An agent that gathers evidence should not silently decide which evidence is authoritative. An agent proposing a consequential action should not necessarily be the component that authorizes it. A model generating a calculation should not replace deterministic computation when an exact result is required.

Orchestration is therefore not merely an architecture of parallel execution. It is an architecture of responsibility.

A recent trust-tiered multi-agent research system demonstrates one possible direction. It separates a deterministic “librarian” from the agents writing a report. The librarian maintains timestamped evidence, source-trust levels, authoritative metrics and relationships between claims. Writer agents consume that reconciled knowledge rather than independently retrieving raw fragments.

The authors report eliminating thousands of contradictions across report sections while preserving point-in-time provenance. The findings still require independent scrutiny, but the architectural principle is valuable: evidence should be reconciled before synthesis, and disagreement or refutation should update the shared knowledge base rather than disappear inside an agent conversation.

Multi-agent quality depends less on the number of agents than on the epistemic infrastructure surrounding them.

Evaluation must move inside the loop

Traditional software testing asks whether a predefined system behaves according to its specification.

AI systems introduce variability at nearly every level. Their behavior may change with the model, instructions, retrieved context, available tools, memory, reasoning effort and sequence of previous actions. Successful testing before deployment cannot guarantee reliable behavior after deployment.

For an agentic workflow, evaluation must examine more than the final answer:

  • Was the evidence sufficient?
  • Were the most authoritative sources used?
  • Did the agent select the appropriate tool?
  • Were the tool parameters correct?
  • Did important constraints survive across the workflow?
  • Is the conclusion supported by the evidence?
  • Is uncertainty being represented honestly?
  • Should the system abstain?
  • Is the proposed action authorized?
  • Did the action produce the intended result?
Evaluation is not something performed after intelligence has completed its work. It is one of the mechanisms through which reliable intelligence is produced.

Evaluation therefore belongs inside the architecture, not only inside quality assurance.

It produces the signals required to improve context, memory policies, agent responsibilities, tool use and operational controls. Without those signals, an organization cannot reliably distinguish an effective system from one that is merely fluent and convincing.

System capability is multiplicative

It is tempting to imagine that a highly capable model will compensate for weaknesses elsewhere in the system. In practice, the relationship appears closer to multiplicative:

Useful AI capability ≈ Model capability × Context quality × Coordination × Evaluation × Control

This is not a literal engineering equation. It illustrates the dependency between the components.

If context quality approaches zero, the system reasons from a distorted reality.

If coordination approaches zero, agents duplicate work, lose information or pursue incompatible objectives.

If evaluation approaches zero, the organization cannot determine whether the result is acceptable.

If control approaches zero, a correct recommendation can still become an unsafe action.

A frontier model cannot independently repair all these deficiencies.

OpenAI recently offered an example of the effect of system architecture. In its builder’s guide to GPT‑5.6, the company reports that retained reasoning and context compaction increased GPT‑5.6 Sol’s ARC-AGI-3 score from 13.3% to 38.3%, while using roughly six times fewer output tokens.

The underlying model did not change. The surrounding execution architecture did.

Vendor-reported results require independent validation, but the broader lesson is significant: some of the largest capability improvements may come not from replacing the model, but from improving the conditions in which it operates.

AI systems have new ways to fail

When an AI system produces a clearly wrong answer, the failure is visible. The more difficult failures occur when the output appears reasonable but the process behind it is defective.

An AI system can fail because it:

  • Received the wrong representation of reality
  • Retrieved outdated or manipulated evidence
  • Remembered an event but lost its surrounding context
  • Assigned responsibility to the wrong component
  • Allowed information to degrade between steps
  • Reached a plausible conclusion without sufficient support
  • Treated uncertainty as confidence
  • Acted before verification or authorization
  • Produced a decision that cannot be reconstructed or audited

AI systems do not fail only by being wrong.

They can fail by knowing the wrong things, remembering selectively, coordinating poorly, acting too early or leaving no defensible account of how they reached a decision.

Conventional monitoring, testing and access controls remain necessary, but they are not sufficient. Organizations also need visibility into context composition, retrieval provenance, memory changes, agent handoffs, tool calls, evaluation results and authorization decisions.

Observability must extend from infrastructure behavior into cognitive behavior.

From model intelligence to engineered intelligence

The next stage of enterprise AI will not be defined only by how intelligent models become. It will be defined by how deliberately organizations engineer the systems through which that intelligence reaches the world.

For technology leaders, the practical questions are changing:

  • What reality are we constructing for the system?
  • Which sources and memories can influence its conclusions?
  • Where are responsibilities separated?
  • How is disagreement resolved?
  • What is evaluated during execution?
  • Which actions require deterministic authorization?
  • When must the system stop and ask for human judgment?
  • Can we reconstruct why a consequential decision was made?

A model can generate an answer without resolving these questions.

A dependable AI system cannot.

The frontier is moving from model intelligence to engineered intelligence—and the architecture surrounding the model is where reliability, accountability and organizational value are created.