When to build an agent

Build an agent when recurring multi-step work needs governed access to real systems. Do not build one for questions a search box answers, for work with no named approver, or for systems that are not connected. This page is the gate in front of Agent config; read it before touching configuration.

Build when all of these hold

• Repeatable outcome. The workload repeats with a recognizable done state: triage, lookups, drafts, remediation, reconciliation. Name 2 to 3 concrete case types, not “everything in the queue.”
• Clear tools and context. You can list what the agent sees (systems, queues, groups, windows) and write the exclusion list. “The usual tools” is not a scope.
• A human approval gate for irreversible steps. Someone owns each risky decision, by role. If no one can name the approver, approvals cannot be designed; resolve that first. Irreversible, customer-visible, or cross-system actions pause; reads and drafts flow.
• Measurable success. The pilot can prove value: a verifiable result per session and a recorded outcome, not a feeling.
• Connected coverage. Every system the workload needs is provisioned, credentialed, and enabled for the tenant’s environment. Code existing is not connected.

Do not build when any of these hold

• One-off advice. A single lookup, summary, or recommendation with no follow-on action needs a session in an existing environment, not a new agent.
• Pure UI chrome. A button, view, or display tweak with no governed work behind it is product surface, not an agent.
• Continuous human judgment every step. If every action needs a person deciding anyway, the agent adds routing overhead without autonomy. Gate the risky steps instead of agent-wrapping the whole flow.
• Wrapping a single API call. One call with no policy, memory, or observability upside does not earn an agent. Expose the tool or the binding directly.
• “Connect everything, sort permissions later.” Ungovernable by construction. Hold the line: scoped or nothing.
• Connector gaps treated as done. If the system is not live for the tenant, the agent is a demo against borrowed data. File the request first (connector intake).
• Success unmeasurable. If the pilot cannot show a recorded outcome per session, the scope is not ready. Rewrite the scope doc.

The check before config

• Scope doc written: workload, org scope, in-scope systems and data, exclusions, read and change needs, risky actions, approver roles, connector gaps, observable success. Template: Discovery.
• Work owners signed off: “yes, this is the work.”
• Red flags cleared: approver named, scope bounded, connectors requested not assumed.

Pass that check and continue to Agent config. Fail it and fix the scope; configuration cannot rescue an unscoped build.