Wait. Why Agentic?

Most conversations about AI agents skip this question. They begin with the agent, then search for a problem dramatic enough to justify it. A planner is added. A few tools are connected. Another agent becomes a supervisor. Soon the architecture has more job titles than a medium-sized company, but nobody can explain why a normal service, decision table, or workflow engine would not have solved the same problem faster and more reliably.

That bothered me.

Traditional software is exceptionally good at deterministic work. If the inputs are known, the rules are stable, and the permitted outcomes can be enumerated, code is usually the right answer. It is cheaper, faster, easier to test, and easier to audit. Adding a model to that path can make the system less predictable without making it more capable.

But there is another class of work where the evidence is incomplete, the next useful action depends on what was just discovered, multiple sources can conflict, and the system must construct a case-specific response while still respecting hard operational boundaries. That is where agentic behavior can earn its complexity.

I wanted to see the boundary, not merely describe it. So I built a demo, a live enterprise agentic systems lab that executes an agentic workflow and a production-strength deterministic workflow side by side against the same evidence.

Try it here: https://aegisops-agentic-portfolio.vercel.app

The first mistake: treating all automation as agentic

Before discussing agents, it helps to separate four forms of control that are often collapsed into one vague category called AI automation.

1. Fixed deterministic logic

This is ordinary code, decision tables, state machines, and workflow engines.

The system knows:

– which fields it needs

– which systems it will call

– which conditions it will evaluate

– which outcomes are permitted

– what happens when no condition matches

For a known case, this is an excellent design. The same facts produce the same result. Test coverage can be exhaustive. Latency and cost are predictable. Auditors can inspect the exact condition that matched.

In AegisOps, this lane is implemented with typed source connectors, Zod validation, deterministic fact derivation, `json-rules-engine`, a safe exception route, and OPA policy checks. It uses the same real evidence boundary as the agent. It is not intentionally weakened.

2. Dynamic policy

Policy is also deterministic, but it answers a different question.

Business logic asks, “What outcome matches these facts?”

Policy asks, “Is this action allowed under the current identity, risk, spend, approval, and data conditions?”

A model should not decide whether it is authorized to send a customer message, dispatch a drone, modify a supplier record, or trigger a rollback. In the demo, OPA/Rego is compiled to WebAssembly and evaluated outside the model. Read-only evidence collection can proceed. Side effects are held for approval.

Policy is dynamic because its answer can depend on context, but it is not agentic. It remains explicit, deterministic, and independently governed.

3. Structured AI workflow

A structured AI workflow uses a model inside a predefined path. The model may classify, summarize, extract structured data, or draft a response, but the application still owns the sequence.

This is useful when semantic interpretation is required but adaptation is not. Many production AI systems should stop here. They do not need open-ended planning or tool selection.

4. Agentic execution

An agentic workflow can choose its next action from an approved set based on the goal and observations available at runtime. It can collect evidence, update state, change the investigation path, hand work to specialists, reconcile results, and stop when the graph’s completion conditions are satisfied.

That freedom must be bounded. The agent does not receive unlimited tools, unlimited iterations, or authority over side effects. It operates inside a typed graph, policy envelope, tool allowlist, cost ceiling, evidence requirement, and evaluation gate.

This is the useful definition of agentic AI for enterprise systems:

“Adaptive decision-making inside an explicit control architecture.”

Without adaptation, it is an AI workflow. Without control architecture, it is a liability.

What actually changes when a workflow becomes agentic?

The important difference is not that the model writes more text. It is where control lives.

In a deterministic workflow, engineers decide the evidence plan before the run. The workflow knows which sources to fetch and how every supported fact maps to an outcome.

In an agentic workflow, engineers define the goal, state, tools, constraints, and completion tests. The model can then select the next evidence action inside that bounded space.

I designed the AegisOps execution story around six stages that make this visible.

Stage 1: Bound the goal

The run begins with a typed case contract. Scope, inputs, approved tools, model, maximum tool calls, spend ceiling, and approval requirements are fixed before model execution.

This is not administrative overhead. It is the autonomy boundary.

The deterministic lane validates its own versioned decision contract at the same stage. It confirms the accepted fields, approved sources, known outcome vocabulary, and manual exception route.

Stage 2: Choose the evidence plan

The agent sees a goal and an approved tool set. It decides which evidence action should happen next.

The deterministic lane uses a precompiled evidence plan. It does not need model tokens and cannot vary between runs unless engineers change the configuration.

Both approaches are valid. The deciding question is whether the next useful source can be known in advance.

Stage 3: Execute typed tools

The agent does not scrape arbitrary pages or call random functions. Every tool crosses an MCP boundary with a typed input schema and structured result contract.

MCP, the Model Context Protocol, is valuable here because tools become portable, inspectable capabilities rather than framework-specific function blobs. The same source tool can be used by an agent, a deterministic service, an evaluator, or another compliant client.

Each call exposes:

– selected tool

– approved alternatives

– validated arguments

– execution actor

– latency

– returned fields

– source URL

– trace identity

The deterministic lane calls the same MCP tools. This keeps the comparison honest.

Stage 4: Validate what came back

External data is not trusted merely because a server returned HTTP 200.

Each source response passes a Zod contract before becoming evidence. Missing, nullable, or malformed fields are handled as contract states, not silently converted into business facts. The SEC workflow, for example, had to accept nullable filing metadata present in the real company-facts document without weakening the required numeric observation contract.

The UI also shows provenance. A field can be a live source observation, a versioned policy snapshot, an operator-supplied scenario input, or an unavailable private connector. Synthetic context is never silently displayed as production evidence.

Stage 5: Adapt or reconcile

This is where agentic value becomes concrete.

A single agent can use returned observations to choose another action or synthesize a case-specific response. A multi-agent graph can send independent evidence tasks to specialists, wait for all handoffs, and reconcile them through a supervisor.

The deterministic lane derives typed facts and evaluates versioned conditions. It is exceptionally strong inside the world its designers encoded. When the case falls outside that world, it routes to a manual exception instead of inventing a response.

Stage 6: Verify the boundary

The answer is not complete merely because the model stopped generating.

OPA checks action authorization. A grounding evaluator verifies that every required operational and policy source produced evidence. Token usage, latency, tool count, and estimated cost are recorded. Any write or external action remains approval-held.

The final state is therefore not “the model answered.”

It is “the graph completed, required evidence exists, policy was evaluated, side effects remain controlled, and the result can be audited.”

“The system exposes execution summaries and control decisions, not private chain-of-thought.”

Why I do not show the model’s hidden reasoning

One of the most misleading phrases in agent demos is “watch the AI think.”

Production systems should not depend on exposing private chain-of-thought. It is not the right audit surface, and a fluent explanation after the fact is not proof that the runtime behaved as claimed.

What an enterprise system needs is **observable decision evidence**:

– what goal was accepted

– which tools were available

– which tool was selected

– what typed arguments were sent

– what validated observations returned

– which specialist handed off to whom

– which policy decision applied

– whether grounding passed

– what action remained approval-held

These are inspectable runtime facts. They can be tested, traced, replayed, and compared. That is far more valuable than a theatrical stream of internal monologue.

Five use cases, five different reasons for or against an agent

A serious agentic portfolio should not repeat the same chatbot pattern with different labels. Each use case should expose a different decision boundary.

1. Production incident investigation

This is the primary multi-agent demonstration.

A platform-health specialist reads live component status. An incident specialist reads unresolved incidents. A policy specialist retrieves the relevant NIST incident-response guidance. LangGraph executes these branches in parallel and waits at a fan-in barrier. A supervisor with no tools reconciles the reports into one operational brief.

Why use multiple agents here?

Because the evidence surfaces are independent, can be collected concurrently, and may need reconciliation. Each specialist has a narrow assignment and tool boundary. The supervisor creates one accountable output but cannot silently collect new evidence.

The deterministic lane remains useful. It can route known combinations of degraded components and active incidents quickly. Its limit appears when evidence conflicts, chronology is ambiguous, or the investigation needs a source that was not encoded into the decision table.

2. Engineering issue triage

The agent reads a real GitHub issue, repository metadata, and NIST secure-development guidance. It identifies the affected surface, missing context, likely investigation path, and approval boundary before any code or repository write.

A deterministic engine can route by issue state, age, label count, or repository status. It cannot reliably infer an implementation path from a changing natural-language issue and repository context unless that semantic work is delegated to a model.

This is a strong example of a single-agent workflow. Multi-agent orchestration would add ceremony without enough independent work to justify it.

3. UAE villa fire response with Hassantuk for Homes

This physical AI scenario combines an operator-supplied alarm envelope, official Ministry of Interior protocol, UAE residential fire-safety policy, and live local weather conditions.

The agentic lane uses three specialists for protocol, conditions, and policy. It prepares a case-specific response recommendation covering alarm priority, resident verification, and whether authenticated drone or thermal overwatch could improve situational awareness.

The demo does not claim access to private Hassantuk alarm history, resident calling, drone control, or Civil Defence dispatch. Those are explicit production connector boundaries. Missing private context is labeled. Calls, drone launch, and dispatch remain behind authorized human approval.

The deterministic lane implements a mature response table. It can evaluate sensor count, verification state, context availability, weather constraints, and approval status. It is not made artificially stupid. Its limitation is its inability to seek unmodeled evidence or construct a new plan for an unfamiliar villa state.

4. Supplier entity risk

The agent resolves a real legal entity through GLEIF and retrieves OECD responsible-business-conduct guidance. It separates entity match evidence from due-diligence judgment and holds supplier status changes for approval.

Rules are excellent at blocking known registration states. Agentic work becomes useful when names are ambiguous, evidence is incomplete, the operating context matters, or the response must explain what additional diligence is proportionate.

5. Finance evidence analysis

The workflow reads live SEC company facts and retrieves SEC materiality guidance. The agent explains the latest filing observation, period, caveats, and why a numerical threshold alone cannot establish materiality.

The deterministic lane can flag missing observations, stale filings, and predefined thresholds. It should do so. The agent adds value when a reviewer needs a grounded narrative that combines quantitative evidence with policy-relevant qualitative context.

RAG is not a search box attached to a prompt

Retrieval-augmented generation is often presented as “put documents in a vector database and ask questions.” That description omits nearly every production concern.

In AegisOps, policy retrieval is a typed, read-only MCP tool. It is not invisible prompt stuffing. Its query and results become normal trace evidence.

Every retrieved policy chunk carries:

– scenario and tenant boundary

– document ID

– authority

– source URI

– title and version

– effective date

– capture timestamp

– content hash

– chunk metadata

– embedding model, when embeddings are enabled

The public deployment uses a versioned MiniSearch lexical corpus so the demo remains fully runnable without paid infrastructure. The managed production schema supports Postgres full-text search and pgvector HNSW retrieval. The MCP contract does not change when the storage mode changes.

This is an important production pattern. The workflow should depend on a retrieval capability, not on one vector vendor.

There are also two different policies involved:

1.Retrieved business policy, such as NIST, OECD, SEC, or UAE guidance that informs the recommendation.

2. Runtime authorization policy, enforced by OPA, that determines whether an action is permitted.

Mixing these together is dangerous. A document saying an action is recommended does not grant the agent authority to execute it.

The full agentic stack, layer by layer

The visible graph is only the top of the system. A production agent is a distributed application with an unusual control loop. Each layer needs a clear owner.

“Each lit component is backed by the same streamed run events that drive the workflow view”

Experience layer: Next.js, React, AI Elements, React Flow, Framer Motion

React Flow renders the workflow and stack topologies. Framer Motion handles stage transitions. AI Elements renders streamed model output and tool states. The interface prioritizes the active decision stage, then exposes raw trace payloads, configuration, costs, and stack details through progressive disclosure.

Manual stepping matters. A production workflow may execute in seconds, but a human trying to understand it needs control over the presentation clock. Runtime truth and presentation cadence are separate.

Streaming layer: Next.js route and AI SDK UIMessage streams

The browser receives typed run events while both lanes execute concurrently. It does not poll a fabricated animation timeline. The UI only lights a stage after the corresponding event exists.

This makes streaming part of the audit architecture, not just a typing effect.

Orchestration layer: LangGraph

LangGraph owns state, fan-out, fan-in, conditional routing, checkpoints, specialist boundaries, supervisor reconciliation, policy steps, and evaluators.

The graph constrains the model. A specialist can be forced to call one assigned tool. A supervisor can be deliberately tool-less. Required branches must reach the fan-in barrier. Completion can be rejected when evidence is missing.

This is why a graph runtime is more appropriate than a long while-loop hidden inside an API handler.

Agent loop: Vercel AI SDK ToolLoopAgent

The model loop owns tool selection and synthesis inside the graph node. Provider adapters keep the workflow portable across GitHub Models, direct OpenAI access, or the Vercel AI Gateway.

The graph and the model loop have different responsibilities. LangGraph controls the workflow. ToolLoopAgent controls the bounded model-tool turn.

Tool plane: MCP and Zod

MCP defines the portable tool boundary. Zod validates tool inputs, external source responses, evidence records, and streamed events.

Untyped tool calling is one of the fastest ways to turn an agent demo into an operational incident. The model should never be responsible for interpreting an undocumented arbitrary payload.

Deterministic decisions: json-rules-engine

The rules lane owns known business outcomes. Rules are versioned, independently testable, and visible in the same execution story as the agent.

This lane is not a legacy appendix. In many enterprise systems it should remain the primary path, with the agent handling ambiguous exceptions or investigation.

Governance: OPA/Rego

OPA owns allow, block, and approval decisions. Rego policy is compiled to WebAssembly for the public runtime. Model prompts can describe policy, but they cannot replace an independent policy engine.

The current public system allows bounded read-only tools and blocks side effects. A managed enterprise deployment can add identity, tenant, role, sensitivity, approval, and four-eyes controls without changing the model’s authority.

State and memory: Postgres, pgvector, LangGraph checkpoints

Memory is not one feature. It includes:

– graph checkpoints

– run state

– conversation state

– retrieved knowledge

– durable business facts

– audit history

These data classes need different scopes, retention periods, write policies, and access controls.

`PostgresSaver` activates when a managed database is configured. The free public deployment can use in-memory checkpoints within a request, but it does not falsely claim durable serverless memory. Postgres and pgvector provide a coherent production target for checkpoints, retrieval, audit, approvals, and tenant-scoped memory.

Observability and evaluation

Every model step, tool call, policy decision, evidence record, handoff, token count, latency, and trace ID becomes an event. OpenTelemetry-compatible tracing provides the cross-system path.

Evaluation is part of runtime completion. The grounding evaluator can fail a fluent answer that did not collect the required evidence. Offline evals and captured-real-run replay then support regression testing without fabricating business records.

Deployment and spend control

The public runtime is deployed on Vercel with request size, rate, concurrency, tool count, spend, model, and duration limits. It is read-only by design.

The UI separates actual provider charge from direct API equivalent cost. The deterministic lane has zero model cost. This makes unit economics visible per decision rather than hiding them in a monthly invoice.

What production-grade really means

“Production-grade” is overused in AI. It does not mean the demo has authentication and a Dockerfile. It means failure, authority, provenance, and cost are designed into the control path.

For an enterprise agent, I would expect at least:

– typed run, state, tool, evidence, and output contracts

– explicit tool allowlists and risk classes

– independent authorization policy

– human approval for write or external actions

– tenant-scoped state and retrieval

– document versioning and content hashes

– durable checkpoints and idempotency

– bounded retries and timeouts

– rate, concurrency, token, and spend ceilings

– traceable model and tool actors

– grounding and behavioral evaluations

– safe exception routing

– replay from captured real runs

– secret isolation and server-side credentials

– mobile and accessible operational UX

The model is one component in that list.

A practical test for deciding whether you need an agent

Before building an agent, ask these questions in order.

• Can the outcome space be enumerated?

If yes, begin with a deterministic engine.

• Can the evidence plan be fully known before execution?

If yes, use a workflow. Add model steps only where semantic interpretation is necessary.

• Does the next useful action depend on observations discovered during the run?

If yes, an agentic loop may be justified.

• Are there independent evidence tasks that benefit from parallel collection and reconciliation?

If yes, consider multi-agent orchestration. If not, keep one agent.

• Can the agent’s freedom be bounded by tools, state, policy, budget, and completion tests?

If no, do not deploy autonomous execution.

• Can you prove what happened without reading chain-of-thought?

If no, the observability model is incomplete.

• The conclusion I reached

Can everything be coded?

In one sense, yes. An agentic runtime is still software. Its graph, tools, policies, schemas, state, and evaluators are all code.

But the real question is whether engineers should pre-code every evidence path and response combination before the system runs.

For stable, enumerable decisions, absolutely.

For ambiguous work where the next investigation step depends on newly observed evidence, where policy and operational context must be reconciled, and where the final response must be constructed for the case, pre-coding every path becomes brittle or impossible.

That is the point where an agent earns its place.

It earns its place when adaptive control produces a better decision than a fixed path, and the surrounding system can still prove what happened, constrain what may happen next, and stop unsafe action.

“Agentic AI is not a replacement for deterministic software. It is a controlled extension of it.”