Before You Build an AI Agent: 7 Decisions Leaders Must Make

Seven decisions that determine whether an agent project succeeds, all of them made before any code exists: the outcome, the autonomy level, the tools, the data access, where a human approves, how it is evaluated, and who owns it.

Published 2026-09-09 · By Shahzad Asghar

The fastest way to fail with AI agents is to start building one. Development is now the easy part; frameworks are mature, models are capable, and a working prototype takes days. What separates the agents that deliver value from the ones that get quietly switched off is a set of decisions that belong to leadership, not to the engineering team, and that are far cheaper to make before the first line of code.

Having reviewed and governed digital initiatives across large international organizations, I keep seeing the same seven decisions either made deliberately at the start or made accidentally, and painfully, in production. Here they are, in the order they should be taken.

Decision 1: What business outcome is this agent accountable for?

Not "we want an AI agent", but a measurable outcome: reduce invoice processing time from nine days to two, resolve sixty percent of tier-one support tickets without escalation, cut duplicate vendor records to near zero. The outcome decision does three jobs at once. It selects the use case, it defines success before anyone is emotionally invested in the technology, and it gives you the kill criterion: if the metric does not move, the agent stops.

A red flag at this stage is an outcome expressed in activity ("the agent will draft responses") rather than results. Activity is what agents produce effortlessly; outcomes are what they must be held to.

Decision 2: How much autonomy does the agent get?

Autonomy is a dial with recognizable positions. An agent can recommend, where a human performs every action; it can draft, where a human approves before anything is sent or saved; it can act with review, where actions execute and humans audit samples; or it can act autonomously within hard limits. Choose the position per action type, based on reversibility and impact, and write it down.

The strongest pattern I have seen is progressive autonomy: every agent starts at draft level, and autonomy is expanded action by action as evaluation evidence accumulates. Autonomy is then something an agent earns with data, not something a vendor slide grants it.

Decision 3: Which tools and actions is the agent allowed?

An agent's real capability is its tool list. Enumerate the specific actions it may take, query this system, update that record, send this category of message, and treat everything not on the list as forbidden. Each tool needs an owner, input validation, rate limits, and logging.

Resist the temptation of broad tools. "Access to the ERP" is not a tool; "create a draft purchase requisition under 5,000 dollars" is. Narrow tools are what make the blast radius of a confused agent small and the audit conversation short.

Decision 4: What data may the agent access, and with whose permissions?

Decide the data perimeter explicitly: which repositories, which record scopes, which classification levels. Then decide the permission model: does the agent act with its own least-privilege identity, with the requesting user's permissions, or both. The safe default is that an agent acting for a user can never see or do more than that user could.

This is also the moment to rule on memory: what the agent may retain across tasks, for how long, and under which privacy rules. Data protection regulators will not distinguish between "the system stored it" and "the agent remembered it".

Decision 5: Where must a human approve?

Mark the red lines in advance: payments and financial commitments, personnel actions, external communications, deletions, anything legally binding. For each, name who approves, what they see when they approve, and how long approval may take before the task escalates. Then make the approval flow cheap enough that people do not route around it; a two-click review with full context survives contact with a busy week, a ceremony does not.

The purpose is not distrust of the technology. It is that accountability must sit with a person, and approvals are where that accountability becomes visible. My deeper piece on what changes when agents join the workforce covers this at organizational scale.

Decision 6: How will you evaluate it, before and after launch?

Agree the evaluation method while everyone is still neutral. That means a test set of real historical cases with known good outcomes, target scores the agent must reach before each autonomy step, and production monitoring for quality drift, not just uptime. Include cost per completed task in the scorecard; an agent that succeeds expensively can be worse than the process it replaced.

If a team cannot describe how the agent will be evaluated, it is not ready to build. Evaluation is to agents what testing is to software, except the stakes include actions, not just outputs.

Decision 7: Who owns and operates the agent?

An agent in production is an operational system with a lifecycle: incidents, model updates, policy changes, permission reviews, retirement. Decide now who owns the outcome (a business leader), who operates the system (a named technical team), who reviews its permissions on a schedule, and who can pull it from service. Agents without owners drift, and drifting agents are the ones that end up in incident reports.

This is also where budget realism lives: the platform capabilities an agent depends on, described in what an enterprise agent platform actually requires, need funding beyond the pilot.

The one-page test

Before approving any agent build, I ask for the seven answers on a single page: outcome and metric, autonomy per action, tool list, data and permission model, approval points, evaluation plan, and named owners. If the page is easy to write, the project is well conceived. If the page is hard to write, you have just saved yourself six months of discovering that in production.

FAQ

What should come first when building an AI agent?

The business outcome and its metric. Every other decision, autonomy, tools, data access, approvals, evaluation, ownership, is shaped by what the agent is accountable for delivering, so it must be fixed first.

How do you decide an AI agent's autonomy level?

Classify each action by reversibility and impact, start every action at draft-and-approve level, and expand autonomy per action as evaluation evidence accumulates. High-impact or irreversible actions keep a human approval gate permanently.

How is an AI agent different from workflow automation or RPA?

RPA follows fixed rules on fixed paths. An agent interprets goals, plans steps, and chooses tools, which makes it flexible on messy work but also non-deterministic. That flexibility is exactly why agents need the governance decisions in this article and RPA largely does not.

Who should own an AI agent in an organization?

Pair a business owner accountable for the outcome with a technical operating team responsible for the system, and put agent permissions into the same periodic review cycle as human access rights. An agent with no named owner should not be in production.

How do you evaluate an AI agent before launch?

Run it against a test set of real historical cases with known correct outcomes, score quality, safety, and cost per task, and set thresholds it must pass for each increase in autonomy. Keep the same measurements running in production to catch drift.

Conclusion

Agents amplify whatever clarity, or confusion, an organization brings to them. Seven deliberate decisions before development turn an impressive demo into an accountable digital worker; skipping them turns the same demo into next year's audit finding.

If you are shaping an agent initiative and want the architectural counterpart to this checklist, read the production platform guide next, or reach out through the contact page. I write regularly here on AI governance for large organizations.

---

SEO Metadata

Title Tag: Before You Build an AI Agent: 7 Decisions Leaders Must Make Meta Description: A practical pre-build checklist for AI agents: outcome, autonomy, tools, data access, human approval, evaluation, and ownership. Decide these first. Target Keyword: before building an AI agent Secondary Keywords: AI agent strategy, AI agent governance, agent autonomy levels, human approval workflow, AI agent evaluation

Internal links used: /ai-agents-in-the-workforce-agentic-enterprise/, /enterprise-ai-agent-platform-production/ Additional internal link suggestion: [INTERNAL LINK: your AI governance pillar page "AI governance framework"]

Schema Markup

``json { "@context": "https://schema.org", "@graph": [ { "@type": "BlogPosting", "headline": "Before You Build an AI Agent: Seven Decisions Leaders Need to Make", "description": "The seven decisions that should precede AI agent development: business outcome, autonomy level, tools, data access and permissions, human approval, evaluation, and operating ownership.", "author": { "@type": "Person", "name": "Shahzad Asghar", "url": "https://shahzadasghar.com", "sameAs": ["https://www.linkedin.com/in/shahzadasghar-ai"] }, "publisher": { "@type": "Person", "name": "Shahzad Asghar" }, "datePublished": "2026-09-09", "dateModified": "2026-09-09", "mainEntityOfPage": "https://shahzadasghar.com/before-you-build-an-ai-agent-seven-decisions/", "keywords": "before building an AI agent, AI agent strategy, AI agent governance" }, { "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What should come first when building an AI agent?", "acceptedAnswer": { "@type": "Answer", "text": "The business outcome and its metric. Autonomy, tools, data access, approvals, evaluation, and ownership are all shaped by what the agent is accountable for delivering." } }, { "@type": "Question", "name": "How do you decide an AI agent's autonomy level?", "acceptedAnswer": { "@type": "Answer", "text": "Classify each action by reversibility and impact, start at draft-and-approve level, and expand autonomy per action as evaluation evidence accumulates. Irreversible actions keep a permanent human approval gate." } }, { "@type": "Question", "name": "How is an AI agent different from workflow automation or RPA?", "acceptedAnswer": { "@type": "Answer", "text": "RPA follows fixed rules on fixed paths, while an agent interprets goals, plans steps, and chooses tools. That flexibility handles messy work but is non-deterministic, which is why agents need explicit governance." } }, { "@type": "Question", "name": "Who should own an AI agent in an organization?", "acceptedAnswer": { "@type": "Answer", "text": "A business owner accountable for the outcome plus a named technical operating team, with agent permissions reviewed on the same cycle as human access rights." } }, { "@type": "Question", "name": "How do you evaluate an AI agent before launch?", "acceptedAnswer": { "@type": "Answer", "text": "Test it against real historical cases with known correct outcomes, score quality, safety, and cost per task, set thresholds for each autonomy increase, and keep the same measurements running in production." } } ] } ] } ``

Image Suggestions

1. Hero: A one-page decision sheet mock-up with seven labeled boxes (outcome, autonomy, tools, data, approvals, evaluation, ownership). Alt text: "Seven decisions before building an AI agent".
2. Autonomy section: A dial graphic with positions Recommend, Draft, Act with review, Autonomous within limits. Alt text: "AI agent autonomy levels".
3. Evaluation section: A simple chart showing autonomy expanding as evaluation scores pass thresholds. Alt text: "Progressive autonomy based on evaluation evidence".

For the cases where the answer is not to build one at all, see when not to build an AI agent. The wider control set sits in agentic AI governance.

← All articles