Deploying an invoice processing agent with Google Cloud Agent Garden

Accounts-payable teams care about speed, control, and traceability. The practical question is simple: can an AI-assisted workflow move invoices faster while keeping payment policy visible and enforceable?

This customer implementation answered that question with a clear yes. I started from Google Cloud Agent Garden, deployed the invoice sample to Agent Runtime, encoded a real policy rule for work authorization, and verified the deployed runtime enforced that rule before payment routing.

The rule we centered was one any finance operator can evaluate:

Repair invoices with billed labor require a work authorization form before payment routing.
Preventative and cleaning work are exempt.

What We Deployed

Agent Garden sits inside Google’s Gemini Enterprise Agent Platform and provides prebuilt agent samples with source code and deployment paths. For this project, it gave us a fast starting point and a structure we could refine into customer policy.

We deployed the invoice workflow into a dedicated Google Cloud project with the following runtime identity:

In the console, the runtime exposed the operational surfaces we needed for trustworthy execution: logs, latency, request count, error rate, and token usage.

How The Workflow Maps To AP Operations

The sample pipeline gave us a strong business shape out of the box:

The deployed agent ran through Gemini via ADK, and the main inference action was run_inference(case_id). That gave us a simple control point for testing policy behavior against known invoice cases.

First Runtime Verification

Our first deployed run used:

Process the invoice for case_001.

The runtime completed and returned:

• run_inference executed successfully
• Decision: REJECT
• Investigation result: PARTIAL_VIOLATION
• Compliance score: 66.67%
• rejection_justified=true
• Output path under /code/invoice_processing/data/agent_output/case_001

That output gave us what operators need: a decision with supporting artifacts, not just model text.

Customer Policy Refinement

We then packaged the customer rule as configuration:

{
  "require_work_authorization": true,
  "waf_exempt_work_types": ["PREVENTATIVE", "CLEANING"],
  "waf_exempt_vendors": [],
  "policy_note": "Customer policy: repairs and emergency work with billed labor require a work authorization form before payment routing."
}

The test fixture was case_005, a repair invoice with no work authorization form and invoice total 1069.32.

With baseline sample settings, Phase 1 continued. With customer policy enabled, Phase 1 rejected with explicit evidence:

{
  "step": "1.4",
  "rule": "Work authorization required",
  "passed": false,
  "evidence": "WAF required for REPAIRS, WAF present: False",
  "rejection_template": "Missing Work Authorization Form"
}

That is the exact handoff business teams care about: a policy condition mapped to a deterministic rejection reason.

Deployed Proof After Policy Change

We validated the policy in the deployed runtime, not only in local checks.

One packaging mismatch surfaced during this step: the first override was YAML while the sample config loader expected JSON. We corrected the packaged config to JSON and redeployed.

After that correction, runtime logs showed the policy path in production infrastructure:

Loaded config from /code/invoice_processing/configs/customer_waf_policy.json
Loaded customer policy config: /code/invoice_processing/configs/customer_waf_policy.json
INFERENCE PIPELINE: case_005
Stage 1/3: Running Acting Agent...
Processing: case_005
Acting Agent: REJECT (took 0.0s)
Investigating case case_005...
Investigation: FULLY_COMPLIANT (score: 100.0%)
Final output: /code/invoice_processing/data/agent_output/case_005

Deployed result summary:

The Audit Layer

The audit artifact for case_005 captured both technical and business signals:

{
  "case_id": "case_005",
  "processing_summary": {
    "decision": "REJECT",
    "processing_time_seconds": 33.38,
    "total_llm_calls": 3,
    "total_tokens": 2806,
    "total_cost_usd": 0.005983
  }
}

For operations, this is the practical output:

• The decision class is explicit.
• The policy reason is inspectable.
• Processing time and model activity are measurable.
• Artifact files support audit and exception review.

Next Implementation Layer: Clerk-Facing Front End

In the next part of this customer implementation, we built the clerk-facing layer that turns this runtime into an AP review desk.

The core UX is straightforward:

The detail view pairs document context with decision context: invoice packet, extracted fields, policy checks, decision summary, investigation status, and audit history.

The target clerk message is plain language:

Rejected before payment routing because this is a repair invoice with billed labor and no work authorization form.

Technical shape for this layer:

Clerk web app
  -> Backend API
    -> Invoice/document storage
    -> Agent Runtime or ADK service
    -> Audit database
    -> Accounting system integration

This keeps cloud credentials out of the browser and preserves a clear system-of-record boundary in the backend.

Responsible Cloud Ownership

After evidence gathering, we deprovisioned resources:

• Runtime list returned empty ({}) for reasoning engines.
• The sandbox project was deleted.
• Project lifecycle moved to DELETE_REQUESTED.

This is a small but important part of production-facing work: prove behavior, capture evidence, and remove cost-bearing infrastructure when the run is complete.

What This Phase Proved

This implementation phase established a practical deployment pattern:

• Fast bootstrap from Agent Garden sample to deployed runtime.
• Customer policy encoded as configuration.
• Deployed runtime verification of policy-driven decisioning.
• Compliance and audit artifacts suitable for operations review.
• Cost and latency signals available for business planning.

The next production integration phase focuses on live intake channels, accounting-system handoff, approval workflows, and regression gates around false accepts, false rejects, and exception routing.

Takeaway

Agent Garden accelerated setup, and the customer value came from policy fit, deployed verification, and operational traceability. That combination is what turns an AI template into useful invoice infrastructure.

References

• Google Cloud Agent Garden documentation
• Google Cloud Agent Runtime deployment documentation
• Agent Garden launch post from Google Developers Blog
• Google ADK invoice-processing sample