AI Agents (Architecture Pattern)
The architecture pattern behind LLM-driven action-taking — a scoped tool-calling loop with permission tiers, bounded orchestration, and decision-trace evaluation — described here at the pattern level, not as a delivery offering.
As an architecture pattern, an AI agent is a bounded loop in which a language model selects from an explicit, versioned set of callable tools, each scoped to a permission tier, within a fixed step budget and explicit stop conditions — not an unrestricted autonomous process, and not a single-shot prompt-and-response call. The pattern's four load- bearing components are the tool/function-calling schema (what the model can call and with what inputs), the permission tiering (which tools are read-only versus state-changing, and which require human approval), the orchestration/loop control (how many steps it can take before it must stop or escalate), and the evaluation layer (how tool-selection correctness is measured, not just final output quality). This page describes that underlying pattern; for how North Tech Labs delivers it as an engagement, see the AI Agents service page.
Where it fits
This pattern earns its complexity in a specific gap: workflows that branch too often for deterministic rules to cover economically, but where the space of legitimate actions can still be enumerated and scoped in advance. If a workflow can be fully expressed as fixed rules, that's a simpler and more predictable architecture. If it genuinely can't be bounded to a defined set of actions, this pattern isn't the answer either — it's built around an explicit tool list, not open-ended system access.
The pattern's components exist to answer one question concretely: what, exactly, is this system capable of doing, and who signs off before it does the parts that can't be undone? The tool/function- calling schema answers what's callable at all. The permission tier answers whether a given call can run unattended or needs a human in the loop first. The orchestration layer answers how long the system is allowed to keep trying before it has to stop and escalate. None of that is optional scaffolding around "the real AI part" — it's the architecture, and skipping it is what turns a demo into an incident.
The pattern is deliberately provider-agnostic. Because the tool schema — not a specific model's behavior — is the actual contract, the underlying language model can be swapped or upgraded without redesigning the permission or orchestration layers, provided the evaluation set is re-run against the new model before its output is trusted in production.
Core capabilities
- Each tool defined as an explicit, versioned function with a strict, typed input/output schema
- Structured schema validation constrains what the model can pass — not free-form text parsing after the fact
- No general-purpose shell, filesystem, or open API access; only the enumerated tool surface is callable
- Malformed or out-of-schema tool calls rejected before they reach any real system
- Read-only lookup tools isolated from state-changing action tools at the authorization layer, not by convention alone
- Every tool carries an explicit risk classification that determines whether it can execute unattended
- Irreversible or high-consequence tools wired to a mandatory approval gate enforced in code, not left to prompt instructions
- Credentials and system access scoped per tool rather than granted wholesale to the agent process
- Bounded step counts and timeout budgets on every run, so an unresolved task terminates instead of looping
- Explicit stop conditions defined independently of "the model decided it's finished"
- Planner shape (single-step, sequential multi-step, or a constrained loop) matched to actual decision complexity rather than defaulted to the most complex option
- Session and context boundaries that stop state from one run silently persisting into the next
- Trace-level logging of every tool call, its arguments, and the model's stated reasoning
- Evaluation sets that score tool-selection correctness and step order, not only the final output text
- Adversarial test cases — malformed tool responses, conflicting instructions, prompt-injected tool output
- Regression evaluation re-run whenever the underlying model, prompt, or tool schema changes
Common use cases
- Bounded operational agentA narrow, explicit tool set for a single workflow — such as a lookup-and-flag pattern — with no ability to call anything outside that list.
- Multi-step orchestrator with checkpointsA sequence of tool calls across more than one system, with a mandatory approval step before any irreversible action in the sequence executes.
- Retrieval-grounded decision supportA retrieval tool combined with a small set of write actions, so recommendations stay grounded in retrievable source data rather than model memory alone.
- Threshold-triggered monitorA watch on a data feed or metric that takes one narrow, pre-approved action when a defined threshold is crossed, escalating anything outside that boundary.
Architecture & integration considerations
- Tool-selection correctness evaluationEvaluation has to score which tool the agent chose, in what order, and why — a trace-level eval set, not a judgment of whether the final output text looked reasonable.
- Human-approval checkpoints before irreversible actionsActions classified as irreversible or high-consequence route to an explicit human approval step before execution, enforced at the orchestration layer rather than assumed from the prompt.
- Failure & fallback behaviorA failed tool call, an unexpected tool response, or an ambiguous instruction has defined behavior — the default is to stop and escalate, not to retry indefinitely or guess and proceed.
- Idempotency & retry safetyState-changing tools need to be idempotent or otherwise guarded, so a call retried after a timeout or a step re-run doesn't silently execute the same action twice.
- Schema & prompt versioningTool schemas and prompts are versioned and re-evaluated against the trace-level test set when changed, rather than redeployed on the assumption that behavior stayed constant.
Strengths
- Handles judgment-heavy workflows rule-based automation can'tEffective where a workflow branches too often for a deterministic rule tree, but where the legitimate action space can still be enumerated and scoped.
- Produces an auditable decision trailTrace-level logging of tool calls, arguments, and reasoning lets a specific decision be reconstructed and reviewed after the fact, not just its final output.
- Authority can expand incrementallyA permission-tiered design supports starting from read-only tools and adding state-changing ones only once evaluation results support it, rather than granting full access up front.
- Portable across model providersBecause the tool schema is the actual contract, the underlying language model can be swapped or upgraded without redesigning the permission or orchestration layers.
Trade-offs & limitations
- Control versus autonomy is the central tensionThe more autonomy a tool tier is granted, the higher the cost of a single wrong action — which is why the pattern's default posture is narrow scope and explicit approval, expanded deliberately rather than assumed.
- Requires evaluation infrastructure most teams don't have yetTrace-level eval sets and adversarial test cases are real upfront engineering investment, distinct from and larger than typical unit or integration test suites — skipping this step is what turns scoped autonomy back into an unaudited black box.
- Tool and permission scoping is nontrivial design workA tool defined too broadly reintroduces the exact risk the pattern exists to avoid; getting the boundary right requires detailed knowledge of the workflow, not just a list of API endpoints.
- No correctness guarantee, even within scopeA model can still select the wrong tool or misread an input inside its permitted action space — approval gates and evaluation reduce that risk, they don't eliminate it.
- Latency and cost compound with stepsMulti-step orchestration multiplies model calls, tool round-trips, and evaluation overhead, unlike a single-shot request/response pattern.
When to use it
- The workflow has too many branching judgment calls for deterministic rule-based automation to cover economically
- The legitimate action space can be enumerated into a fixed, explicit tool list
- Irreversible or high-risk actions can tolerate a human-approval checkpoint without breaking the workflow
- There's capacity to build and maintain trace-level evaluation before expanding action authority
When another option may be more appropriate
- The workflow can be fully expressed as deterministic rules — rule-based automation is simpler, cheaper, and fully predictable
- The required actions can't be safely enumerated into a bounded tool list
- No approval step is possible for irreversible actions and tolerance for a wrong action is zero
- There's no capacity to build and maintain a trace-level evaluation set before granting any write access
Relevant industries
- ManufacturingCustom manufacturing software, operational platforms and connected systems for companies modernising production across Sweden and the Nordic region.
- Logistics and MobilityCustom logistics, fleet, mobility and transport software for companies managing complex operations across the Nordic region.
Alternatives & complementary technologies
- Deterministic rule-based automationWhen workflow logic is fully expressible as fixed rules, rule-based process automation gives predictable, fully explainable behavior without any tool-scoping or evaluation-infrastructure overhead.
- Single-shot LLM call without an orchestration loopFor a lookup-and-respond pattern with no sequential tool use, one model call against retrieved context is architecturally simpler than a bounded agent loop and has fewer failure modes to guard against.
- Human-only review workflowWhere a wrong automated action is intolerable and volume doesn't yet justify an automation investment, keeping the decision fully human remains the lowest-risk option.
Frequently asked questions
How is this different from a single LLM API call?
A single API call is one request and one response. This pattern describes a loop: the model can select from a defined set of tools, take a bounded number of steps, and stop or escalate under explicit conditions — closer to a constrained decision process than a single generation.
How do you decide which permission tier a tool belongs in?
By classifying the tool itself at definition time — whether it's read-only or state-changing, and whether its effect is reversible — rather than inferring risk from the agent's behavior at runtime.
What actually stops an agent from looping indefinitely?
A bounded step count and a timeout budget defined at the orchestration layer, plus explicit stop conditions that don't depend on the model itself deciding it's done.
How do you evaluate an agent differently from normal software testing?
Evaluation has to score the decision path — which tool was called, in what order, and why — not just whether the final output looked correct, plus adversarial cases like malformed tool responses and conflicting instructions.
Is this pattern tied to a specific LLM provider?
No. The tool schema, not a specific model's behavior, is the actual contract, so the underlying model can be swapped, provided the evaluation set is re-run against it before its output is trusted.
Considering AI Agents (Architecture Pattern) for your next project?
Tell us what you're building — we'll confirm whether this is the right technology choice before recommending anything.