Approval-bound support workflow agent

The problem you will solve

A support assistant can look up a fictional order and propose a refund. The model may recommend an action, but only deterministic server policy and explicit user approval can authorize it. Build a recoverable workflow rather than a chatbot that can call any function it names.

Before you start

Tool schemas, transactions, authorization and API error handling.

Suggested tech stack

• Python
• SQLite
• FastAPI
• State machines
• pytest

Data plan

Create a sandbox of 20 fictional orders with eligible, ineligible and already-refunded states. Store approval records and append-only events; never connect this portfolio demo to real payment or email systems.

Hardware and cost

Develop the state machine with a stub planner first, which requires no model or GPU. Optionally add a small model adapter for intent planning, with strict token and tool-call budgets.

Define the input and output

Use this illustrative contract as a starting point, then specify required fields, validation and error responses in your own implementation. It is not a complete API schema.

States: received → planned → awaiting_approval → executing → completed / failed / cancelled
Action: {"order_id":"demo-12","amount":100,"approval_id":"...","idempotency_key":"..."}

Your five build milestones

Finish and test one milestone before extending the system. Keep an experiment log with the decision, the alternative you rejected and the evidence behind the choice.

1. Define legal transitions

   Represent each workflow state explicitly. Specify maximum tool calls, allowed operations and cancellation points; reject unknown tools before any execution.

2. Build safe sandbox tools

   Implement read_order and propose_refund against seeded SQLite fixtures. Enforce ownership and eligibility on the server, independent of model output.

3. Bind approval to action

   Show the exact order and amount for confirmation. Bind a single-use approval record to those values and expire it; a changed amount requires a new approval.

4. Make recovery idempotent

   Record action outcomes transactionally with a unique idempotency key. Simulate a timeout after a successful write and prove that retrying does not issue a second refund.

5. Test adversarial paths

   Inject instructions through order notes, restart during execution and cancel before approval. Export a redacted event trace that explains every transition and denial.

How to evaluate your project

Set your acceptance criteria before looking at the final test results. The checks below are proposed experiments, not measured outcomes or a guarantee that a particular model will pass.

• Assert that no write occurs without matching, unexpired approval and server-side eligibility.
• Replay the same action ten times and verify one sandbox side effect.
• Report completion and safe-denial rates separately across fixed normal, malicious and interrupted scenarios.

Save your test cases, run command, dependency versions and results together. Compare on identical inputs, retain failures in the denominator and report sample sizes. If a change improves one metric but harms another, explain which trade-off fits your use case.

Failure modes worth demonstrating

• Treating model confidence as permission or letting a model fabricate an approval ID.
• Retrying a side effect without an idempotency record after an ambiguous timeout.

Optional extension

Add a dry-run view showing proposed changes and a recovery report for interrupted tasks.

Turn the build into portfolio evidence

Your repository should let another person understand the problem and reproduce the core evaluation without needing your private credentials.

• A README with problem, intended user, architecture, setup commands and a small input/output example.
• A permitted sample dataset, its origin or generator, a frozen test split and a single evaluation command.
• A results table comparing your baseline with your final approach, including failures and sample counts.
• A short demo or screenshots, a limitations section and one decision you would change with more time.
• Environment-variable names without secret values, a dependency list and attribution/license notices for any reused code or datasets.

Resume framing

Describe this as a personal or educational project. State what you implemented, how you tested it and what your measured results were. Replace placeholders with your own evidence; do not claim employer impact, production traffic or accuracy you did not measure.

Built approval-bound support workflow agent using Python, SQLite, FastAPI; evaluated against [baseline] on [N held-out cases], documented [measured result] and [important limitation].

Be ready to explain your decisions

• What if the tool times out after committing?
• Why is a prompt saying 'ask permission' insufficient?

Answer with a concrete failure from your implementation, the options you considered, your measured evidence and the limitation that remains.

Google documentation and GitHub references

The project scope, milestones and evaluation plans above are original AIJobFever educational material. These official Google resources offer background or implementation examples; they are not finished implementations of this blueprint. No Google endorsement is implied. Review repository licenses, supported platforms and current costs before reusing code or provisioning services.

• Google: ADK GitHub recipes ↗