Enterprise AI agents: an operating guide.

An agent is an operating model for work

An enterprise AI agent is not simply a conversational interface connected to several tools. It is a bounded way of completing work: a trigger begins a run, an identity determines access, policies constrain the available actions, evidence supports decisions, a person owns exceptions, and the final state can be reconstructed.

That operating model matters more than the novelty of the model. NIST organizes AI risk management around four continuous functions—Govern, Map, Measure, and Manage—rather than a one-time release checklist.Source 1 Its Generative AI Profile extends that lifecycle view with practical attention to system scope, data lineage, pre-deployment evaluation, human oversight, incident responsibilities, monitoring, override, recovery, change management, and eventual decommissioning.Source 2

The useful executive question is therefore not where an agent might fit. It is which workflow has a clear owner, a measurable terminal state, tolerable failure consequences, and enough evidence to evaluate every run.

1. Start with a bounded workflow

Describe the work before selecting the automation pattern. A useful workflow brief names:

• the event that starts the work;
• the person accountable for its outcome;
• the systems the process reads and changes;
• the authoritative sources it may rely on;
• the output that marks completion;
• the conditions that require human judgment; and
• the largest acceptable consequence of an incorrect action.

Strong first candidates are frequent enough to evaluate, repetitive enough to compare, and narrow enough to contain. Examples include preparing a meeting brief from approved systems, classifying an inbound support request, drafting a reconciliation package, or assembling evidence for a reviewer. Ambiguous negotiations, irreversible commitments, and poorly documented exception-heavy processes are poor starting points because there is no stable definition of success.

IBM's account of AskHR illustrates the importance of separating routine work from complex cases: common requests are handled through automation while human advisers remain responsible for work that requires judgment.Source 3 IBM's broader transformation retrospective also describes an early satisfaction decline and recommends beginning with a smaller pain point, learning from users, and expanding deliberately.Source 4 These are IBM's self-reported program lessons, not expected results for another organization.

2. Define the autonomy envelope

Autonomy should be expressed as explicit permissions, not as a vague label such as autonomous or supervised. For every system, separate what the agent may read, draft, recommend, approve, and execute. Then add limits based on consequence: monetary value, record count, data sensitivity, destination, time window, and reversibility.

A research agent may read approved sources and draft a summary. A support agent may update an internal classification but require approval before issuing a credit. A finance workflow may prepare an exception package but stop before a payment or ledger change. The model can propose an action; the execution layer should decide whether that action is permitted.

This boundary should be versioned with the agent configuration. When a prompt, model, tool, policy, or knowledge source changes, the organization should be able to identify which version produced a run. Without that record, a change that improves one scenario may silently weaken another.

3. Curate data and tool access

Give the agent the minimum context required for its assignment. Start with named knowledge sources and narrow actions. Treat retrieved documents, email, websites, and tool responses as untrusted inputs rather than privileged instructions. Validate structured outputs before they reach another system.

Tool design deserves the same care as API design. A narrowly scoped create-draft action is easier to authorize and test than unrestricted mailbox access. A bounded search endpoint is safer than arbitrary database queries. Downstream services must still enforce tenant, role, and resource authorization; a model's decision is not an authorization decision.

In Zilionix, the repository-verified platform surface includes Advanced/ReAct, workflow, and supervisor agents, 42 workflow node types across seven categories, Semantic, MMR, HyDE, hybrid, and multi-query retrieval, and configurable tool attachments. Those are implementation facts, not evidence that a particular customer workflow is production-ready. The workflow owner still has to define permitted sources, actions, and exceptions for each deployment.

4. Put approvals at consequence boundaries

Review every consequential decision, not every intermediate thought. Approval is most useful immediately before an external message, financial action, destructive change, publication, entitlement update, or other difficult-to-reverse step. The reviewer should receive the proposed action, relevant evidence, policy result, and a concise explanation of the exception.

Approval design also needs rejection, timeout, and escalation behavior. A stalled approval should not be interpreted as consent. A rejected action should leave an understandable terminal state. In the current Zilionix workflow implementation, the human approval node is terminal: approval records the decision and ends that execution. Any subsequent write requires a separately initiated continuation.

5. Make every run produce a receipt

A useful receipt is a compact operational record, not a transcript dump. It should identify:

1. the trigger and initiating identity;
2. relevant input provenance and retrieved sources;
3. the agent, model, prompt, tool, and policy versions;
4. proposed and completed tool calls;
5. validation and policy outcomes;
6. the approver and decision, when applicable;
7. the final output or changed state; and
8. latency, cost, failure, and terminal status.

Receipts support investigation, evaluation, and accountability. They do not prove that a decision was correct, and storing more content is not automatically better. Sensitive inputs should be minimized or referenced by protected identifiers where possible.

6. Evaluate the workflow, not just the answer

Define acceptance criteria in business language before rollout. A support response can be relevant yet fail to resolve the request. A reconciliation can be numerically consistent yet use the wrong source period. A routing decision can be semantically plausible yet violate an access policy.

Evaluation should therefore cover task completion, correctness, escalation, policy violations, tool errors, human corrections, rollback, and the final state in connected systems. Maintain representative examples, difficult edge cases, and known failures. Run regression evaluations whenever a prompt, model, knowledge source, tool, or workflow changes.

Salesforce describes a staged internal rollout that began with a limited authenticated cohort before expanding.Source 5 Its published answer-quality framework evaluates responses against expert-approved criteria and combines response quality with outcome measures such as resolution and escalation.Source 6 Salesforce also notes limits in model-based evaluation and the need for human calibration. These are first-party operating practices from Salesforce, not independent benchmarks or Zilionix performance claims.

7. Roll out in controlled stages

A practical release sequence is:

• Offline evaluation: replay representative scenarios without external actions.
• Shadow mode: compare recommendations with the existing process while humans remain in control.
• Internal cohort: let trained users work with constrained permissions and explicit feedback paths.
• Limited production: activate a narrow set of reversible actions for a defined group.
• Broader rollout: expand only after evaluation, incident handling, ownership, and support processes remain stable.

Each stage should have an exit criterion and a rollback path. Expansion is a governance decision based on evidence, not a calendar promise. There is no universal fixed implementation timeline.

8. Assign durable ownership

Every production workflow needs a business owner, an evaluation owner, a security owner, and a destination for exceptions. The operating team should review drift, failed runs, approval queues, access changes, knowledge freshness, cost, and user feedback. It should also define when to suspend, replace, or retire the workflow.

The platform can supply building blocks—agents, workflows, knowledge retrieval, approvals, audit records, observability, and publishing interfaces. The organization remains responsible for process design, source authority, permissions, evaluation criteria, reviewer capacity, and incident response. Explore those surfaces in Platform, Security, Developers, Use cases, and Pricing.

Source boundary

NIST publications are voluntary risk-management guidance, not certifications. IBM and Salesforce describe their own programs and report their own outcomes; their experiences should inform rollout design, not forecast results. References to Zilionix in this guide describe repository-verified capabilities as of the review date. They do not claim public customer deployment, operational performance, regulatory compliance, or a complete organizational control program.

The durable principle is straightforward: begin with bounded work, grant limited authority, place people at consequence boundaries, evaluate the resulting state, and preserve enough evidence to understand every run.