AI Agents, Agentic AI and Enterprise Context: Follow the Decision

AI-assisted article. The interactive examples use fictional records and scripted decisions. No model is running in this page.

Follow a decision before choosing an architecture

An agent might read a maintenance ticket, inspect an equipment manual and propose a new inspection date. A conventional workflow can do much of this through fixed steps. An agent becomes useful when the next step depends on what it discovers: request another observation, search a different manual or ask a person to resolve a conflict.

The engineering question is where those decisions live and what limits them. A diagram showing several agents does not answer whether any of them has permission to change the maintenance schedule.

Agentic behaviour can exist in one agent

An AI agent usually combines a model, tools and an execution loop. The term is used inconsistently. An agentic system gives a model some influence over its next steps. It can contain one agent or several. Neither term guarantees unrestricted autonomy, long-term memory or learning.

Anthropic’s Building effective agents distinguishes predefined workflows from agents that direct their own process. That is a useful architectural distinction, not a universal definition. The page also warns that its tooling discussion has evolved since its original publication.

A single agent can investigate a ticket across several tools. A multi-agent workflow can remain tightly scripted. Count decision points and authority boundaries rather than treating the number of agents as a maturity score.

Context changes the proposal; authority controls the effect

Illustrative scenario: a fictional composite written to make the point concrete. It does not describe a real organisation, and its figures are not reported outcomes.

A maintenance planner receives a request to defer a pump inspection. An agent finds an earlier deferral and a manual that appears relevant. The current asset register identifies a different pump revision, and a recent observation records vibration outside the normal band. Those facts should change the proposal.

The earlier precedent cannot authorise a new deferral. The schedule service must still check the caller, current asset state and the applicable approval. The proposed date may be sensible while the action remains unauthorised.

The Contextual Agentic Enterprise (CAE) is the author’s proposed architecture and operating model for connecting enterprise context, delegated authority and outcomes. It is a synthesis, not an industry standard. In this interpretation, retrieval informs reasoning while the system that owns the record controls commitment.

The CAE explanatory model Deterministic Shell / Probabilistic Core separates model-led interpretation from executable checks. This is a design intention. Its effectiveness depends on complete mediation, correct policies and dependable implementation; a labelled box cannot establish those properties.

A team needs a reason to exist

Use another agent when it adds a useful independent task, access boundary or specialism that can be evaluated. For example, a documentation worker might locate the relevant manual while an observation worker checks recent readings. A controller must reconcile their results against the same asset identity and time window.

More agents introduce more messages, intermediate outputs and possible failure paths. Shared memory also creates questions about who may write, overwrite or trust a claim. A second model repeating an unsupported conclusion does not provide independent evidence.

Start with the simplest design that meets the task. Compare a fixed workflow, a single agent and a coordinated system on representative cases. Measure accepted outcomes, unauthorised-action attempts, unresolved cases, elapsed time and total operation cost. The article supplies no benchmark showing that one configuration wins.

Put the controls on the execution path

A practical implementation keeps tool selection separate from tool execution. A model may propose reschedule_inspection, but a service validates a structured request against the authenticated caller and current record. The model does not supply its own permission.

Record the request key before attempting a consequential action. If the result is uncertain, reconcile with the owning service before retrying. An observation saying ‘request timed out’ does not mean the schedule stayed unchanged.

Each loop needs an externally enforced step limit, time limit and cost budget. A model instruction to ‘be efficient’ is insufficient. A specialist worker’s budget also has to fit inside the overall run budget.

A useful run record includes the evidence used, proposed action, applicable rule version, approval where required and the service’s actual result. Logs may contain sensitive information, so collection, access and retention need deliberate design.

Implement and test the boundaries

The companion interactive diagram is an executable presentation of the control flow. Switch architecture, play or step through the phases and inspect the hand-off. It is scripted educational behaviour; it does not call a model or modify an external service.

For a production implementation, write an adapter around the actual scheduling service and exercise at least these cases:

• A valid proposal succeeds once and a repeated request key returns the same recorded result.
• An asset revision changes between retrieval and commitment, causing re-evaluation.
• A worker returns a manual for the wrong asset, and the controller rejects it.
• A tool response contains instructions to ignore policy, and these remain untrusted data.
• The run exhausts its budget or loses a dependency, preserves its state and stops clearly.

These are acceptance criteria, not evidence that those controls have been deployed. The browser demonstration only verifies its own interactions.

Choose an architecture the operating team can explain

Keep a bounded agent when it meets the task. Add coordination when a specific division of work earns its cost. Add enterprise context by binding evidence to the relevant business object and current situation, rather than simply expanding the prompt.

This approach does not solve poor source quality, missing ownership, incorrect authorisation rules or organisational disagreement. A model can surface those gaps; an accountable owner still has to resolve them.

The book develops the broader relationship between enterprise context, delegated authority and evidence. This explainer introduces those concerns without reproducing the book’s examples.

Continue with the companion article, Vector Search to Grounded Context. It shows how evidence reaches an agent before any action is considered.