How AI assistants work: architectures and tradeoffs | AI Wars of 2026

Technical drill-down for the assistant landscape. Source-backed analysis from AI Wars of 2026.

Loop Engineering

From architecture to practice

Loop Engineering: A Better Way to Think, Create, and Work with AI

Explore the practical side of working with AI. The companion site includes chapter resources, worked examples, prompts, and vendor comparisons.

Buy the book on Amazon

Explore the companion site

As an Amazon Associate I earn from qualifying purchases.

How AI assistants work: architectures and tradeoffs

This chapter is the technical companion to AI Assistant Competitive Landscape.

Executive summary

AI assistants share components, but they do not all organize work in the same way: producing a grounded answer, scheduling constrained work, investigating a question, and executing an open-ended task create different requirements for context, control, and verification. The documented patterns below provide a more useful basis for comparison than a universal component-count score. One product can support several patterns, and multi-agent coordination can wrap a research or action workflow rather than form a separate class of product. Choose an architecture for its task fit, then test correct authorized completion, human effort, cost, and recovery; the sources reviewed do not establish an overall performance ranking. C2 C9 C12 X4 E5 E6

Introduction

An assistant that answers a policy question and an assistant that changes a customer record may use similar models but do different work. The first needs relevant, authorized evidence and a supported answer. The second also needs permission to change the record, a valid operation, confirmation of the resulting state, and a response to partial failure. Counting both systems' models, connectors, or memories does not establish which is better.

Here, architecture means the arrangement of context, decisions, tools, state, and oversight around a task. It does not mean the identity of the underlying LLM. We group product modes and configured workflows, not entire companies. Microsoft 365 Copilot's documented answer flow is one example; it does not describe every Copilot product. A research mode and an action mode from the same provider may need different diagrams.

The grouping has direct support in engineering descriptions. Anthropic distinguishes predefined workflows from dynamically directed agents and describes patterns that can be combined. Its Research engineering account documents a coordinator delegating independent investigations to workers. Those sources support recurring patterns, not exclusive market clusters or a ladder on which more elaborate designs are always stronger. The older pattern article now warns that its tooling examples have changed; we use its design distinctions, not those examples as a current product inventory. E5 E6

Each section leads with a conceptual architecture diagram, then identifies assistant modes with supporting documentation and the potential advantages and disadvantages of that arrangement. The diagrams are abstractions, not reverse-engineered production blueprints. Dashed connections are optional or configuration-dependent. In particular, an outcome-checking box identifies what must be evaluated; it does not certify that every named product performs an independent check.

The pros and cons are architectural tradeoffs to test, not measured product results. Primary documentation verifies what a provider describes, while independent evaluation is still needed to establish how well it works. Detailed product evidence, product-scope limits, and a proposed testing method follow in the appendices. Source notes identify the documentation behind the descriptions; no overall strength score is assigned.

Architecture 1: Conversational and grounded-answer assistants

How it works. The main deliverable is an answer, explanation, conversation, or draft. Retrieval and memory can improve the context supplied to the model, but the task does not require the assistant to commit an external action. This functional view does not imply a single model call or disclose the provider's internal routing.

Assistants that work in a similar fashion

Pros and cons

Best fit: conversation, grounded questions, explanation, and drafts reviewed by a person.

What would establish strength: supported answers, relevant coverage, good handling of missing evidence, privacy-respecting context use, and lower human correction effort on matched tasks.

Architecture 2: Constrained workflows and schedulers

How it works. A predefined process or constrained optimization problem determines much of the work. An LLM can help interpret inputs or perform a step without directing the whole workflow. A scheduler can adapt to changed deadlines without being a general-purpose autonomous agent. E5

Assistants that work in a similar fashion

Pros and cons

Best fit: repeatable, bounded operations with explicit constraints and observable success conditions.

What would establish strength: feasible results, faithful constraint handling, fewer unwanted changes, and less human effort than manual work or a simpler automation.

Architecture 3: Adaptive research agents

How it works. The system chooses subsequent searches in response to what it finds. Its principal outcome is an evidence-based artifact rather than a change to a customer account, calendar, or production system. This is an adaptive-agent specialization, not an entirely different technological foundation from the action architecture. “Assess evidence” is a function to evaluate, not a claim that the assistant independently verifies every source.

Assistants that work in a similar fashion

Pros and cons

Best fit: questions requiring multiple sources, uncertain search paths, and a reviewable synthesis.

What would establish strength: better claim support and material coverage, calibrated uncertainty, and acceptable effort/cost compared with simpler retrieval and human-led research.

Architecture 4: Adaptive action agents

How it works. The system selects actions, observes feedback, and changes its plan while pursuing a goal. Actions may alter external state, so authority, confirmation, duplicate prevention and recovery become central. A depicted result check is not proof of a product-wide verification guarantee. C12 E5

Assistants that work in a similar fashion

Pros and cons

Best fit: bounded goals requiring adaptable execution, where progress and destination state can be checked.

What would establish strength: correct authorized completion under normal and failure conditions, with manageable intervention, bounded cost, and explicit recovery limits.

Architecture 5: Coordinated multi-agent systems

How it works. A coordinator divides work among agents with their own instructions, context or tools, then integrates the results. The worker count shown is illustrative. Workers may themselves be research agents or action agents, so this is a composition pattern across the other families, not a higher capability tier. Model routing, multiple API calls, or a list of specialist functions does not alone establish multi-agent coordination. E5 E6

Assistants that work in a similar fashion

Pros and cons

Anthropic reports gains for selected breadth-first research tasks, alongside substantial resource costs and limitations on tasks requiring heavily shared context. That supports a conditional design choice, not “multi-agent is strongest.” E6

Best fit: valuable work with genuinely separable subtasks and an effective integration step.

What would establish strength: better task outcomes or useful time savings than a strong single-agent baseline under declared resource budgets, after accounting for coordination and human review.

Choosing an architecture without forcing every assistant into one group

Keep placement and access dimensions separate. Browser versus app, device versus cloud, personal versus enterprise, persistent versus session-only, and one model versus model routing describe additional dimensions. They can be drawn as labeled boundaries around several of the patterns above.

• Alexa+ and Siri/Apple Intelligence combine conversational, routing and action functions across service or device boundaries. Use task-specific views; the selected sources do not justify a single exclusive placement or a complete shared internal algorithm. D5 D6 D7 D8 D9
• Poe is a platform of bots; classify the selected bot and mode, not the catalog as if every feature belonged to one runtime. X2
• Phind remains unassigned because no current readable primary product body was obtained. Lack of access is not an architecture. X14
• Other provisional fits remain marked in the tables rather than being forced into an exact blueprint. A less detailed disclosure does not establish a weaker product.

The shared component vocabulary remains useful, but as a comparison aid across these diagrams rather than a universal machine that every product must resemble. The proposed groups would need revision if product-level tracing showed materially different control paths, or if independent reviewers could not assign the same modes consistently. They have not been established as statistical market clusters.

Appendix A: Test the premise: does more mean stronger?

Competing hypotheses

H1 — component complementarity. A relevant new component improves a defined outcome when it removes a real limitation: authorized organizational retrieval may improve document-grounded answers; an action tool may enable a workflow previously limited to drafting; saved state may prevent loss of completed work.

H2 — coordination and exposure cost. Additional tools, memories, agents, or integrations introduce selection ambiguity, irrelevant context, stale state, latency, cost, and opportunities for unintended actions. A narrower system may perform better on its intended task.

Both have concrete support for investigation:

Decision: use H1 to generate specific advantage hypotheses, and H2 to design the counter-tests. Reject “more components therefore stronger” as an unvalidated inference.

Would revise: a matched, repeated, independently checked evaluation shows a meaningful gain from a specified component change at an acceptable cost and risk. A larger product catalog, vendor testimonial, or model benchmark alone would not meet that condition.

Appendix B: Component model and evidence vocabulary

These are functional slots, not proprietary modules that every vendor must implement separately. A deterministic scheduler need not contain an autonomous planning loop. A read-only research assistant need not have authority to purchase anything.

Evidence states for diagrams

• D — documented mechanism: a primary technical/help page describes a particular behavior. Not independently tested here.
• A — announced or described: product copy or a high-level vendor explanation; implementation/availability can be limited.
• U — unestablished: not established by the sources checked. Not “absent.”
• F — future/beta qualification: retain the source's rollout or development boundary beside the affected capability.
• T — task-tested: reserved for a specified, reproducible evaluation. No product-wide T ratings are awarded in this document.

Do not turn D/A/U into 3/2/0 and add them. A proprietary assistant may disclose less than an open runtime while performing better. That is a documentation gap, not a performance score.

Use equal-sized slots. Color can indicate functional role, while letter labels indicate evidence state. A missing or undisclosed component receives an explicit U, not a blank cell that looks like zero.

Appendix C: Detailed product/component evidence map

The “possible advantage” column is a hypothesis to test, not a finding of superiority. References apply to the mechanisms in their row. Product eligibility, configuration, connected-account permission, and task choice remain part of the comparison unit.

General-purpose and workplace products

Consumer, device, and browser products

Specialists, aggregators, and operator-run systems

Developer runtimes: useful evidence, separate panels

These are not additional capabilities to silently add to the corresponding consumer product rows:

• OpenAI Agents SDK: tools, loops, handoffs, guardrails, MCP, sessions and tracing are developer-runtime affordances. Direct Responses API use may leave loop, dispatch and state ownership with the developer. C4
• Gemini API: the model proposes function names/arguments; the application executes the function. Validation, API authentication and recovery remain implementation work. C7
• Copilot Studio: generative orchestration selects tools, topics, knowledge and agents. Testing exposes an activity map; reset/cancel behavior has specific limits. This is not the architecture of every Microsoft 365 or consumer Copilot experience. C10
• Claude Code / Agent SDK: context-action-verification loop, tools, sessions, permissions and checkpoints are documented. Remote database/API/deployment changes are not covered by file checkpoints. SDK affordances are not consumer chat defaults. C12 C13

Appendix D: Product identity and scope

These distinctions limit which product features can be compared.

Appendix E: Validation plan before any claim of strength

Define the comparison unit

Record product + mode + plan + model/version when disclosed + device/OS + region + connected accounts + permissions + settings + test date.

For hosted products that silently change, report the observed configuration and dates; do not pretend it is a reproducible pinned model. For open runtimes, record the runtime revision and operator configuration. An open runtime is not a directly comparable “assistant” until it is configured.

Begin with separate task families

These are evaluation proposals, not claims that every listed product supports every task. Use synthetic or permissioned sandbox data and avoid live purchases, external messages, or destructive actions.

Proposed measures and their denominators

No values for these measures were produced in this research pass.

Controlled changes and disconfirmers

• Hold the task set, permitted data and authority fixed. Predeclare success checks, limits, repetitions and exclusions.
• Compare a simple non-agent workflow or manual workflow where it is a plausible alternative.
• Change one component at a time when technically possible: retrieval, relevant tool, extra irrelevant tools, memory, or verification step.
• Test both clean and adversarial/unreliable conditions: stale information, revoked access, ambiguous instructions, missing tools, timeouts, and untrusted content.
• Check external state independently. The assistant's own “done” message is evidence of reporting, not of completion.
• Randomize or counterbalance trial order, preserve trajectories, and blind human judging where feasible.
• Select sample size for a predeclared meaningful difference and appropriate uncertainty analysis. An initial pilot finds defects; it does not establish a leaderboard.
• If completion improves only because the variant gets more time, a larger model or more human help, do not attribute the gain to component quality.
• If added components worsen selection, latency, privacy exposure or unsafe actions without meaningful task gains, revise H1 for that task.
• If a simpler workflow performs equivalently, do not claim the more elaborate assistant has demonstrated additional value.

“Better component” must name a mechanism

Acceptable hypotheses include “retrieval supplies a required authorized record,” “a narrower tool schema reduces invalid arguments,” or “a checkpoint preserves completed work after interruption.”

“More integrated,” “more autonomous,” “better ecosystem,” and “more components” are not test results. Break each into an observed mechanism and its task-level effect before giving it visual prominence.

Source notes

All links below were retrieved or attempted on 2026-09-27. Page dates are reproduced only when the retrieved page supplied them. “Undated” means no publication/update date was established from the body or metadata inspected.

General-purpose and workplace documentation

Consumer, device, and browser documentation

Specialist and open-system documentation

Evaluation research

Return to AI Wars of 2026