Fabrikam Finance is designing three agents for invoice processing: IntakeAgent (parse invoices), MatchingAgent (3-way match PO/receipt/invoice), and PaymentAgent (initiate payment). Compliance requires that no agent may release payments above $25,000 without a finance manager approval. How should the architect specify autonomy levels and behavioral guidelines?
Select an answer to reveal the explanation.
Short Explanation
Autonomy isn’t one-size-fits-all. You can let intake and matching run autonomously inside narrow read/parse and match scopes, but payment above $25,000 needs supervised autonomy with a mandatory human approval step. That keeps high-risk money movement under control while preserving useful automation.
Full Explanation
AI-500 expects architects to specify agent personas, scopes, boundaries, and autonomy levels explicitly. The correct approach differentiates autonomy by risk: parse and match can be highly autonomous within read/compute scopes, while payment initiation above a monetary threshold requires supervised autonomy and a human-in-the-loop approval control.
Granting all three agents full autonomous write access to the payment system and relying on post-payment audit sampling is wrong because post-payment audits do not prevent unauthorized high-value releases; they only detect issues after money moves.
Disabling PaymentAgent entirely and requiring humans to process every invoice manually in the ERP is wrong because removing PaymentAgent discards valid automation for low-value invoices that can safely auto-process under policy.
Giving MatchingAgent unrestricted payment initiation rights because matching accuracy implies payment authority is wrong because tool and authority scopes must be least-privilege. Matching accuracy does not confer payment rights; conflating analysis agents with action agents creates dangerous privilege concentration.
Exam caveat: Autonomy levels should track blast radius — high financial impact actions default to supervised or constrained autonomy.