Enterprise teams are moving from chat-based assistants to systems that can take actions. I see the shift in how people describe the work. They ask for an assistant that can write code, file tickets, update CRM records, run a compliance checklist, generate a pull request, and follow through on the next step. That shape of work requires an agentic system.
I define an agentic system as software that turns a user goal into a sequence of steps, executes those steps through tools, keeps track of what happened, and produces an auditable outcome. The model contributes planning and language. The surrounding system provides authority, state, verification, and control.
[ See also: “How to run enterprise GenAI like a production service” ]
The engineering question stays consistent across domains. How do you give the system enough autonomy to be useful while keeping outcomes predictable. A production answer comes from constraints that are explicit and enforced.
Adnan Masood
An agent loop is the repeated cycle the system follows to complete work. I use a simple loop and I make each stage observable.
These words carry specific meanings in implementation. Planning produces a structured intent. Action uses a limited interface with a defined schema. Verification runs deterministic checks. Commit writes the versioned state and the trace context.
A tool is any callable capability outside the model. It can be an API, a database query, a workflow engine, a code repository action, or a browser automation step. Tool use dominates operational risk because tools can change systems of record.
A tool contract is the boundary that makes tool use safe to operate. I write it down as part of design review. A contract includes the following:
This contract turns an agent into a regular distributed system client. It becomes testable. It becomes debuggable. It becomes something an operations team can own.
Policy in an agentic system means rules the runtime enforces on every step. I treat policy as an executable module. It sits in the request path. It is versioned. It emits an audit event on decisions.
Common policy domains include data access, tool allowlists, approved destinations for writes, required citations for retrieved material, and refusal rules for restricted requests. Policy starts simple and grows based on incident learning.
State is the durable record of what the agent knows and what it has done. I keep state outside the model. I persist it with a clear schema. I version it per step.
I store at least the goal, the plan steps, tool inputs and outputs, verification results, and the final decision. I also store the retrieved sources when retrieval is part of the loop. This state supports replay during incidents and supports evaluation later.
Teams that keep state only in a conversation buffer lose the ability to reason about behavior at scale. A durable state store supports retries, handoffs, and governance reporting.
Verification is a set of checks that run before a write and after a tool call. I use deterministic checks whenever possible. I treat the model output as an input to be validated.
Examples include schema validation, permission checks, reference integrity checks, and constraints on target systems. For content workflows, verification includes citation coverage and checks for restricted data.
I also use a confidence policy for high-impact actions. The system can require a human approval step for certain tools or destinations. Approval works best when it is narrowly scoped to a clear action with context and evidence.
Adnan Masood
Evaluation for agents focuses on end-to-end task completion and on safety properties. I define task success criteria as observable facts. The ticket exists. The record was updated with the correct fields. The pull request passes checks. The change request has the right approvals.
I create scenario suites that cover routine tasks and edge cases. I run them with fixed seeds where possible and with stable tool mocks. I also run a small set of live tests against a staging environment with realistic data.
I track metrics that connect to operations. Task completion rate by scenario. Average steps per task. Tool error rate. Verification failure rate. Human approval rate. Mean time to recover when a tool returns partial results.
I build production agents with a supervisor pattern. A supervisor owns policy, routing, and state. Specialized workers handle narrow tasks such as retrieval, summarization for a ticket, or a repository action. Workers run with the minimum permissions required for their contract.
A simplified sketch looks like this:
def run_task(goal, user):
ctx = start_context(goal, user)
while ctx.open_steps:
intent = planner.propose_next(ctx)
intent = policy.enforce_intent(intent, ctx)
call = tool_router.bind(intent, ctx)
result = call.execute(idempotency_key=ctx.step_key)
checks = verifier.run(intent, result, ctx)
ctx = commit_step(ctx, intent, result, checks)
if checks.requires_approval:
ctx = wait_for_approval(ctx)
return ctx.outcome
This structure keeps authority in the supervisor. It keeps tool permissions narrow. It gives operations teams a single place to enforce policy and observe behavior.
I use a short set of practices when teams want agents to run safely in production.
I look for these elements before a team runs agentic workflows at scale.
Agentic systems fit enterprise work because they connect language interfaces to business systems. The systems operate well when autonomy sits inside explicit constraints. Constraints turn agent behavior into something teams can measure, improve, and trust.
—
New Tech Forum** provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to *** doug_dineley@foundryco.com.*