Architecture note · AI systems

Agentic AI architecture

Use an agent only when the path to the outcome cannot be enumerated in advance. When autonomy is justified, treat the agent as a bounded software system with typed tools, explicit state, termination conditions and deterministic authorization.

By Salah AwadUpdated 30 August 20268-minute read

The decision boundary

Choose a deterministic pipeline when the steps and ground truth are known. Choose an agent when the system must select and sequence actions dynamically—and only when that flexibility creates enough value to justify the additional risk, latency and evaluation cost.

A bounded task such as transcription, classification, extraction or retrieval normally belongs in a pipeline. Multi-step research, cross-system investigation and exception handling may justify an agent because the correct path depends on intermediate observations.

Decision signalPipelineAgent
Execution pathKnown or enumerableDepends on intermediate results
Ground truthExact or directly measurableHeuristic or outcome-based
Latency and costPredictableVariable and iteration-dependent
Side effectsExplicit workflow stagesMust be separately authorized
EvaluationPer-stage regression testsTrajectory, tool and outcome evaluation

Minimum production controls

Typed tool surface

Expose named, domain-specific operations with validated schemas. Do not give the model a generic HTTP or database client.

Termination contract

Provide a designated completion path, iteration ceiling, time budget and deterministic stop conditions.

Separated authorization

The model proposes an action; deterministic policy evaluates identity, scope, target and current state before execution.

Bounded context

Limit and label tool results to reduce context flooding, accidental disclosure and instruction contamination.

Persisted trajectory

Record model decisions, tool names, normalized arguments, policy outcomes and side effects for reconstruction.

Layered evaluation

Test tool selection, argument validity, policy compliance, termination behavior and final task outcome independently.

Failure modes to design out

  • Unbounded loops: the system continues calling tools without convergence or a hard ceiling.
  • Confused deputy behavior: the model inherits the user’s broad authority instead of receiving operation-specific scope.
  • Prompt-injected tool use: retrieved content influences a privileged action without a deterministic policy boundary.
  • Silent partial completion: the agent reports success while required steps or validations remain incomplete.
  • Unreconstructable decisions: logs capture prose but omit the exact tool arguments and policy result.

Operational rule

An agent that may restart a service should not thereby gain the ability to delete it. Capability boundaries belong in executable policy, not in a system prompt.

How to evaluate the architecture

  1. Establish deterministic baselines before testing an agentic alternative.
  2. Measure task completion and unsafe action rate separately.
  3. Test adversarial retrieved content and malformed tool results.
  4. Measure iteration count, latency and cost distributions—not only averages.
  5. Replay recorded trajectories against policy and outcome assertions.

Authorship and evidence scope

This note is a first-party description of Salah Awad’s architecture practice, derived from systems and patterns represented on the portfolio. Client and programme identities are intentionally withheld. It should be cited as professional analysis, not as independent validation of confidential delivery claims.