Skip to main content

Common Agentic Workloads

(Design a known system shape, review it with the pillars, document the trade-offs)

When you build cloud systems, you typically start from requirements, design a solution, review it with a well-architected method, adjust, and record trade-offs. AWS describes that neglect of core pillars makes it difficult to build systems that meet expectations. (docs.aws.amazon.com) This section provides the same muscle memory for agentic systems: common workload patterns you can design toward, then review with the Agentic Architecture Framework.

What this section is​

Workload patterns are solution archetypes — familiar system shapes such as a knowledge assistant or a customer service chatbot. Each page gives you:

  • a default architecture shape;
  • a small set of critical design decisions (rubrics);
  • where AAF review pressure usually concentrates;
  • common failure modes;
  • prompts for documenting trade-offs.

Vendor and research guidance increasingly organises agentic systems around recurring design patterns and a complexity spectrum (direct model call → single agent → multi-agent orchestration), rather than treating every product as a unique invention. (learn.microsoft.com; docs.cloud.google.com; anthropic.com)

What this section is not​

  • It is not an SDK or vendor cookbook.
  • It is not a catalogue of orchestration topologies (supervisor, swarm, handoff graphs). Those remain implementation detail inside a workload. (developers.openai.com)
  • It is not a replacement for the six pillars or the two cross-cutting foundations. The pillars remain the review method; workloads are the starting design shape.

How to use​

  1. Pick the closest workload from the index below. Prefer the nearest fit over inventing a hybrid on day one.
  2. Run its critical design decisions. Resolve knowledge access, actuation authority, verification, and related rubrics before choosing frameworks.
  3. Attach universal overlays: Agent Control Contract (ACC), Tool Gateway, budgets, epistemic gates, and provenance tagging. These apply to every workload. OWASP frames excessive functionality, permissions, and autonomy as root causes of damaging agent actions. (genai.owasp.org)
  4. Review with AAF using the pillar docs and the application method (Mode 1 design spec, Mode 2 review). Lean on the “AAF review focus” section on the workload page.
  5. Document trade-offs using the trade-off log prompts. Record what you chose, what you rejected, which pillars improved, and which absorbed the cost. Name the pairs (for example Security × Autonomy), not only a single pillar.
Requirements
  → Pick workload pattern
  → Decide critical design rubrics
  → Attach ACC / gateway / budgets / gates
  → AAF pillar review
  → Adjust
  → Document trade-offs

Trade-offs are the point​

No agentic system scores highly on every pillar and cross-cutting foundation at once. Architecture is the deliberate choice of which lenses you strengthen and which you accept as constrained for a given workload, risk appetite, and operating budget.

Read each workload page for:

  1. Cost × Accuracy × Speed — the classic AI triangle (maps to Cost Optimization, Reliability / grounded quality, and Performance Efficiency).
  2. Cross-pillar trades — e.g. Security × Autonomy, Reliability × Cost, Performance × Autonomy Governance.
  3. Design defaults — the recommended starting point, and what that choice usually buys vs spends.

Cost × Accuracy × Speed​

Model selection, retrieval depth, verification, and autonomy all move this triangle. OpenAI frames choosing a model as balancing accuracy, latency, and cost for the workload rather than defaulting to the largest model. (platform.openai.com)

If you prioritise…You typically spend…Common mechanisms
Accuracy / grounded qualityCost↑ and/or Speed↓Stronger models, more retrieval, citations, validators, evaluator loops, HITL
Speed / low latencyAccuracy↓ and/or Cost↑ (or both)Smaller models, less context, fewer tool rounds, fewer gates — or expensive fast paths
Cost efficiencyAccuracy↓ and/or Speed↓Smaller models, tighter context, budgets, early stop, deterministic stages

Agentic systems add a fourth practical dimension: Autonomy. More agency without budgets and gates usually worsens Cost volatility and Security exposure even when Speed looks better on the happy path. (genai.owasp.org; platform.openai.com)

Every workload page includes a Dominant cross-pillar trades block. Use it to force an explicit ADR: what you bought, what you spent, and why that imbalance is acceptable.

Minimum complexity heuristic​

Start with the least complex control structure that can reliably achieve a verifiable outcome. Anthropic, Microsoft, OpenAI, and Google converge on this point: add multi-step or multi-agent structure only when simpler approaches fall short. (anthropic.com; learn.microsoft.com; developers.openai.com; docs.cloud.google.com)

  1. Prefer a deterministic or model-assisted workflow when steps are known and the model need not own the control loop. Microsoft positions a direct model call below agentic architectures when a single pass is enough. (learn.microsoft.com)
  2. Else use one bounded agent with a constrained tool set, budgets, and exit conditions. OpenAI advises starting with one agent and adding specialists only when capability, policy, or prompt isolation materially improves the workflow. (developers.openai.com)
  3. Add structure only when it creates demonstrable value:
    • ordered stages with validated handovers (Anthropic’s prompt chaining with programmatic gates); (anthropic.com)
    • true parallelism for independent work;
    • specialist routing when domains or permissions diverge;
    • ownership handoff across trust or domain boundaries; (developers.openai.com; learn.microsoft.com)
    • independent evaluation when quality requires a separate check (evaluator–optimizer). (anthropic.com)

Do not select multi-agent topologies because they appear advanced. Google Research reports material multi-agent overhead and, on sequential reasoning tasks, large performance degradations across multi-agent variants under fixed budgets. (arxiv.org; research.google)

Workload index​

WorkloadUse when
Knowledge / RAG assistantAnswers must be grounded in a corpus or curated knowledge base
Customer service chatbotDialogue plus live account tools, escalation, and audit
Internal copilotAssistive help over repos, docs, or ops context
Workflow automation agentMulti-step business process with tool writes and a verifiable end state

If none fit cleanly, compose from the nearest workload and say so explicitly in the trade-off log — do not hide a novel architecture behind a familiar label. Real systems often combine patterns by stage rather than wearing a single label. (learn.microsoft.com; anthropic.com)

Sources​

Discussion
Sign in with GitHub to comment