RESULT · AGENT FIT CHECK

Should This Be an Agent? · Sample report (fictional case)

The case: triage and spare-parts coordination for a manufacturer's after-sales tickets. Tickets come in as free text (text, photos, voice transcripts). A technician first checks the equipment record and warranty status in the CRM, then checks the inventory system for parts; if a part is missing, the plan changes to a transfer or an outside purchase, and the customer gets a reply at the end. Refund commitments and warranty decisions, once sent out, cannot be revoked.

Why

Decisive · Decision Autonomy 4/4: the next step depends on the current result and the plan must adjust mid-run, which is the reason agents exist.

Task Variability 3/4: there are real branches and a long tail, so a fixed process needs exception paths.

Feedback & Tool Interaction 3/4: returned results affect branches, but there is no repeated feedback loop yet.

The economics: volume is steady, rules could handle most of it, and the long tail is the part worth spending inference on.

On multi-agent: the decomposability probe shows no need for parallel roles. One bounded agent is enough, and multi-agent would only add coordination cost.

On multi-agent systems: nothing in your answers is evidence that you need one.

The step-down option

If you do not build the agent yet: cover the fixed parts with an AI-assisted workflow and keep the most judgment-heavy segment human.

What must be controlled before launch

• Access Control: least privilege. Grant only the systems and data the task needs, with credentials isolated and never mixed with personal accounts.
• Observability: full logging, a cost ceiling, and a kill switch. Every step replayable, spend stops at the cap, and a human can halt it at any time.
• Approval Points: irreversible or outward-facing actions must pass a human confirmation before execution; the agent never executes them directly. In this case, refund commitments and warranty decisions always pass a human before they go out.
• Tools: callable tools and parameter ranges are allowlisted, write actions are registered one by one, and anything off the list is refused.
• Platform: per-task caps on steps, duration, and budget are set in advance; hitting any cap stops the run and hands it to a human.
• Orchestration: what counts as done and what must stop the run are written in advance as verifiable criteria; a model's own claim of completion is never accepted.

Logic v2 · Demo data, not a real use case.