Agent, automation, or software: decide by uncertainty, repetition, and differentiation
By Equipo Quantum Developers
Summarize:
The right solution depends on three observable variables—decision uncertainty, workflow repetition, and strategic differentiation—not on whether an AI agent appears more modern than automation or conventional software. When those variables lack evidence, selection becomes a vendor preference and correction costs appear later as exceptions, maintenance, and risk.
Before the triangle: frame the whole problem
Do not start with “we need an agent.” Describe the user, business object, outcome, journey, exceptions, systems, decision, and consequence. The GOV.UK Service Standard advises teams to solve a user's whole problem rather than organizing a service around technology or an administrative fragment.
Also ask whether anything should be built. A policy adjustment, data improvement, or capability already present in the system of record may remove the problem with less operating surface.
Axis one: uncertainty
Uncertainty is the interpretation needed to turn variable evidence into a proposal. It is low when inputs and rules are complete and stable, and high when language is unstructured, sources conflict, or context changes.
An agent can help classify, summarize, retrieve evidence, and propose under uncertainty. That does not grant authority. As error consequence rises, action boundaries should narrow and review should become more explicit.
Axis two: repetition
Repetition is not just volume. A process is repeatable when states, rules, inputs, and outputs remain similar. A frequent flow redesigned for each case is a poor candidate for rigid automation; a less frequent but fully stable flow may be suitable.
The OMG BPMN 2.0 specification supplies vocabulary for tasks, events, gateways, errors, escalation, and compensation. Modeling the process reveals whether a governable sequence exists or whether the work is only a collection of tacit decisions.
Axis three: differentiation
Differentiation asks whether a capability encodes an advantage or operating model the organization must control and evolve. High differentiation can justify custom software: identity, state, rules, experience, or integration central to the business.
Low differentiation favors an existing product or automation over stable interfaces. A proprietary system for a generic function creates maintenance without advantage.
Primary-choice matrix
| Uncertainty | Repetition | Differentiation | Primary mechanism |
|---|---|---|---|
| low | high | low | existing product or deterministic automation |
| low | high | high | custom software with explicit rules |
| high | sufficient | low | assistive agent over a governed workflow |
| high | sufficient | high | proprietary software with bounded AI components |
| high | low | any | human work, research, or redesign |
| low | low | low | do not build or use a simple tool |
“Sufficient” depends on stability and available learning, not a universal threshold. The table selects the core; integrations, interface, and controls may combine mechanisms.
Decision tree
- Does an existing product solve the journey and controls? Yes: configure or buy before building.
- Are input, rule, and outcome deterministic? Yes: use workflow, integration, or RPA according to the surface.
- Can ambiguity produce a verifiable proposal? Yes: use an assistive agent with sources and reasons.
- Is action reversible and policy-bounded? Yes: consider graduated autonomy; no: retain approval.
- Does the capability differentiate the business and require proprietary state? Yes: design custom software and place AI only where interpretation adds value.
- Is there no owner, data, or outcome criterion? Do not build yet.
The NIST AI RMF calls for mapping context, responsibilities, impacts, and risks before measurement and management. The AI choice should follow that analysis rather than precede it.
Illustrative examples
These examples are illustrative, not universal recommendations.
Copying data between portals with stable fields: uncertainty is low and repetition high. An integration or deterministic automation is more auditable than an agent interpreting every screen.
Classifying supplier emails and preparing a reply: uncertainty is moderate, the outcome reviewable, and differentiation low. An assistive agent can propose category and draft; a person retains sending authority for sensitive cases.
An allocation engine incorporating proprietary commercial rules and historical state: repetition and differentiation are high. The core belongs in custom software; a model may interpret input text but should not hide allocation rules.
An unprecedented exceptional decision with no agreed criterion: uncertainty is high and repetition low. Keep human analysis. Automating a nonexistent policy merely makes improvisation opaque.
Compare alternatives through one evidence packet
The GAO Cost Estimating and Assessment Guide recommends a technical baseline, assumptions, data, alternatives, sensitivity, and updates with actual costs. For each option record:
- included scope and exceptions;
- build, license, integration, and change cost;
- operations, review, incidents, and maintenance;
- dependence on vendors, models, and interfaces;
- exit risk and cost;
- expected outcome and stop criterion.
Do not compare an annual license with only initial development cost. Do not value an agent without review, evaluation, and observability.
Hybrid architecture with explicit boundaries
A common solution uses software for identity and state, automation for deterministic transitions, an agent for ambiguity, and people for irreversible authority. Each boundary needs a contract: input, output, reasons, timeout, error, retry, and compensation.
The agent should not become universal glue. If a stable API can validate or write, use it. Reserve interpretation for evidence that actually needs it.
Representing the choice in Quantum
Quantum Automation Center can catalog agents and automations without requiring a shared engine. Executions, status, timelines, artifacts, and logs make the journey observable; permissions and human approval constrain action; analytics compare outcomes. The automation documentation places heterogeneous capabilities under a shared control plane.
The architecture decision remains outside the platform slogan: Quantum observes and governs the chosen components.
Counterargument: almost everything is hybrid
Real solutions are often hybrid and resist a single category; the triangle does not prescribe one platform, but identifies the primary mechanism and boundaries between components. A hybrid label does not remove the decision; it requires justification for each part.
If every box ends as “agent plus software plus RPA,” analysis failed. Name where state lives, where rules apply, where ambiguity is interpreted, and who authorizes.
When not to use this tree
Do not use it as a substitute for buy-versus-build analysis, legal assessment, or whole-service design. Do not build any option when an existing product solves the problem without relevant differentiation.
Do not decide before stabilizing the process. If teams disagree about object, outcome, or exception, prototype the service and policy before automating.
The choice test
Explain the solution without naming technology: which uncertainty it resolves, which part repeats, which capability differentiates, where state lives, and which action needs authority. If that explanation naturally leads to the selected mechanism and shows why alternatives lose, the architecture has a defensible reason. If it begins with “we want AI,” the decision is still missing.
Sources
Article topics
