Before You Build Your
Agent Portfolio:
A Go/No-Go Framework

Business considerations — should we build this at all?

This is the filter most teams skip — when they are working in a silo (shadow IT), disconnected from business priorities (sidecar AI), or have unclear requirements (failed pilots). They see a workflow, imagine an agent, and start building.

Three questions stop bad projects before they start:

1. What is the business value of automating this workflow? Not in general terms but specific metrics mapped to your OKRs. Does automating this reduce cost, increase throughput, reduce error rate, or free up skilled human capacity for higher-value work? If the answer requires significant assumptions to be positive, pause here.
2. What is the cost to execute this at scale? Agentic workflows are not free. LLM inference, orchestration, data retrieval, monitoring, and human review all have costs that compound with volume. A simple and cheap prototype can become expensive at production scale. Model the unit economics before building.
3. Is the organization ready — and is the workflow designed for it? The most common reason agentic workflows fail is when the agent is bolted onto an existing workflow rather than built into a redesigned one. Two things have to be true: the people or systems downstream need to trust the outputs enough to act on them, and the agent needs to trigger naturally at the right moment with the right context. Adoption is an architecture and upstream design problem, not a change management issue that comes as an afterthought.

Architectural filters — can we build this technically?

Assuming the business case holds, three technical filters determine whether the workflow can be transformed with AI:

1. Can the workflow be decomposed into clear, deterministic steps? Agents work best on tasks that can be broken into discrete, verifiable sub-tasks with clear inputs and outputs. Workflows that require continuous human judgment, contextual improvisation, or ambiguous decision criteria are not agent-ready — they are copilot candidates at best.
2. Is the data feeding this agent reliable and connected? This is the most underestimated filter. An agent is only as good as the data it reasons over. If the underlying data is siloed, inconsistent, poorly governed, or stale, the agent will produce outputs that are confidently wrong. Data readiness is the prerequisite, not a production-time problem.
3. Which specific steps can actually be replaced by an agent — and which require human judgment? Not every step in an automatable workflow should be automated. Identifying the exact boundary between agent execution and human decision is a core design question. Workflows where that execution boundary is unclear should not be automated.

Architectural design requirements — how do we build it well?

Passing the first two steps means you have workflows worth building. Now I put on my PM hat. This step determines whether you build it in a way that is safe, trustworthy, and improvable over time.

1. Modularity. Requirements change, models improve, and business logic evolves. A well-designed agentic system allows individual components to be upgraded, replaced, or reconfigured without rebuilding the whole. Design for change from the beginning.
2. Guardrails: security, governance, explainability. What can the agent access? What is it prohibited from doing? Can a human understand why it took a specific action? These are the conditions under which the organization will trust and scale the system — they should be part of the design from day one.
3. Observability as a first-class requirement. You cannot govern what you cannot see. Real-time visibility into what the agent is doing, what data it is accessing, and what decisions it is making is not a monitoring feature added after launch. If you cannot instrument it from the start, you cannot operate it safely at scale.
4. Feedback loop and drift detection. Agents degrade over time as the world changes and their training data becomes stale. The system needs a mechanism to detect when outputs are declining in quality and a process to retrain, recalibrate, or escalate when that happens.
5. Human handoff protocol. When the agent stops — because it has reached its execution boundary, encountered an exception, or requires authorization — what exactly does it communicate to the human who takes over? In what format? With what context? The handoff is not just a failure state; it needs to be designed explicitly.
6. Rollback design. When an agent makes a mistake — and it will — what is the minimum blast radius? Can the action be reversed? Can the system detect that something went wrong before downstream consequences compound? Systems that cannot be safely reversed should not be fully automated.