AI agents vs. workflows: choosing the right control model
Use a workflow when the path is known. Introduce an agent where runtime judgment earns its complexity—and keep consequential actions under explicit control.
A reading path / Architecture
AI architecture and integration
Choose the control model, integration boundary and evidence path for an AI product. A curated reading path for CTOs and engineering teams.
Start with the task and the platform it must fit. A model can investigate, classify or propose, while application code owns identity, domain rules and consequential execution. The first architecture decision is where judgment is useful and where the process should remain explicit.
The guides here move from that control decision to the integration contract and the evidence the system needs. Use them to prepare a design review, compare a proposal or identify the uncertainty worth testing before a larger build. They are not a requirement to adopt every component or pattern.
A useful design explains both the accepted task and its failure paths. If a tool times out, a record changes or a user loses access, the engineering team should know whether to resume, reconcile or stop. Those answers matter more than the number of frameworks in the diagram.
01 / Architecture
Choose the control model
Decide who selects the next step before choosing the implementation stack. A fixed workflow, a bounded agent and a multi-agent design have different operating costs and failure modes. Compare them on the same task evidence. The reference architecture then identifies the boundaries that remain necessary whichever pattern is selected.
AI agent architecture: a reference design
A reference architecture for identity, state, tool execution, permissions, evaluation and recovery—with a concrete workflow a CTO can inspect.
Single agent vs. multi-agent systems
Compare single-agent and multi-agent designs through task evidence, coordination cost, context handoff and responsibility for the final action.
02 / Architecture
Connect to the product
An AI capability should inherit the platform’s business rules, not create another version of them. Map the existing identity and mutation path, then expose the smallest useful task contract. MCP can help compatible clients share that surface; a direct API can remain the appropriate choice for a controlled internal workflow.
Integrating AI into an existing enterprise platform
Add AI capabilities through existing identity, domain APIs and data contracts. Plan the migration, rollout and recovery before introducing autonomous writes.
MCP vs. APIs: where each belongs
Compare MCP and direct APIs for discovery, domain behavior, permissions and execution. Decide when a shared protocol interface is useful.
Build vs. buy AI agents: decide what you need to own
A layer-by-layer framework for enterprise AI agent decisions, with a comparison matrix, pilot acceptance criteria and an exit test.
03 / Architecture
Choose the evidence path
Diagnose whether the system lacks current facts or fails a stable behavior. Retrieval, output constraints and training address different problems. Keep source access and freshness visible in the architecture, and use a controlled experiment to establish which change improves the accepted outcome.
RAG vs. fine-tuning: diagnose the missing capability
Choose retrieval or fine-tuning by diagnosing missing knowledge and behavior. Compare freshness, access, evaluation evidence and operating requirements.
RAG evaluation: test retrieval, answers and access
Separate retrieval quality, answer support and permission failures. Use a small worked corpus to understand what each metric establishes—and what it misses.
Permission-aware RAG: access before retrieval
Preserve tenant and source permissions through retrieval, context assembly, caching and citations. Treat revocation and index freshness as part of the design.
From reading to a decision
Bring a concrete architecture question.
A useful review begins with the workflow, existing systems, data boundary and decision the team needs to make. The result should explain the recommended design, alternatives and evidence still needed before committing to the next stage.
Explore an architecture review