-
-
Active n Completed Biddings
-
Agents Calalogue
-
Bidding Listing
-
Bidding Loading
-
ERP Simulation
-
Inventory Alert Bidding
-
Inventory Alert Loaded
-
Inventory Alert Loading
-
LPO Delivered
-
Security Alert
-
Supplier Loading
-
Supplier Listed
-
Agent Gateway
-
Agent Memory
-
Agent Deployment
Inspiration
In modern enterprises, procuring even routine, urgent items like a MacBook M4 is bogged down by weeks of tedious administrative bureaucracy, despite ready supplier inventory and competitive pricing in the market. This project breaks through that bottleneck by deploying autonomous AI agents powered by Model Context Protocol (MCP) to handle the end-to-end procurement workflow—from multimodal spec extraction and real-time supplier discovery to competitive bidding. By automating sourcing and presenting the top verified offers for 1-click human confirmation, the platform collapses weeks of administrative delay into same-day identification, ordering, and delivery.
What it does
The fleet has two independent entry points — a Purchase Requisition is released in the ERP, or stock drops below a reorder threshold — and all two converge on the same agent pipeline. From there: a the agent normalizes the spec (Gemini 3.5), a Sourcing agent discovers authorized suppliers from a real Agent Registry, a Bidding agent queries live quotes concurrently from three supplier ERPs over real MCP servers, and a Ranking agent scores offers on price, delivery SLA, and trust with a compliance justification a human can actually read.
How we built it
All the business logic — RFQ intake, ERP polling, inventory alerts, the procurement workflow, PO governance, memory — runs as one deployed Vertex AI Agent Runtime instance. A thin Cloud Run service sits in front of it and does nothing but relay calls; the frontend talks to that engine directly through its own contract instead of a REST API we bolted on. The procurement workflow itself is a Google ADK Workflow graph: deterministic nodes handle governance and routing, agent nodes handle the judgment calls, and human approval points use ADK's RequestInput pattern to pause. For the very last step — waiting for a person to say go before the order goes out — we used a LongRunningFunctionTool, so the agent parks mid-turn on a pending tool call and only continues once we feed back the human's answer, sometimes hours later. Session state lives in Vertex AI's native session service, so a case's whole history — every pause, every resume — shows up as one connected record instead of scattered logs. The four supplier and ERP systems are MCP servers running on Cloud Run, reachable only with signed identity tokens. Gemini 3.5 runs through Vertex AI's global endpoint, which we landed on after regional endpoints kept failing. A scheduled job checks on paused work every two minutes. Firestore holds the transactional data, and Cloud Trace carries the execution spans, including the workflow engine's own internal tracing.
Challenges we ran into
Gemini 3.5 kept 404ing on every regional Vertex AI endpoint we tried, with nothing in the error explaining why — it turned out the model only answers on the global endpoint, and we ended up hardcoding that into a model subclass since the platform reserves the usual environment variable and won't let you override it. We hit a nasty concurrency bug in our async bridge: a fresh thread and event loop on every call meant a shared Firestore session client, once tied to its first loop, broke the moment a second loop tried to reuse it. It only surfaced once we were processing more than one item per request, so our earlier single-item testing never caught it. Switching the session backend mid-build from something we'd hand-rolled to Vertex AI's native session service meant migrating every session ID to a stricter format and re-checking every human-approval step before we trusted it in production — we tested the riskiest parts on their own first, then watched the whole thing run live before calling it done. And two of the six governance pieces we wanted, Model Armor and Agent Gateway, turned out to be Google Cloud products we simply didn't have access to yet — locked behind an early-access program, even with full admin rights on the project. Rather than fake our way around that, we built our own version of the protection they'd provide and said plainly in the writeup which parts were the real managed service and which were ours.
Accomplishments that we're proud of
We held ourselves to a strict rule throughout: nothing counted as done until it was re-verified against live infrastructure, not just a passing local test. That discipline paid off directly — it's how we caught a real concurrency bug that only showed up under actual concurrent load, and how we confirmed Agent Identity as a genuine kill-switch by disabling a real IAM connector live, watching access get denied, and re-enabling it, rather than assuming the config was correct because it looked right on paper. We proved the end-to-end reasoning-chain trace the same way, with an actual trace ID showing three separate requests, minutes apart, correctly nested under one session. And we shipped three separate foundational migrations — the Security & Governance layer, real Agent Identity enforcement, and a full session-backend swap — in a single day, with zero unresolved regressions in the final, fully re-tested system.
What we learned
hat Google Cloud's own platform boundaries are worth understanding precisely rather than assuming: Vertex AI's global-endpoint requirement for Gemini 3.5, the native session service's strict ID format, and the framework-detection distinction between a raw ADK Agent and a custom orchestration class all shaped real architecture decisions along the way. That distributed tracing across an asynchronous, human-gated workflow is a genuinely hard problem the platform can actually solve — but only if you build on its native session and telemetry primitives instead of hand-rolling your own; the native answer turned out simpler and more capable than anything we would have built from scratch. And that when a platform capability is gated behind access we don't have, the right move is to say so plainly with evidence, not to quietly paper over it with a workaround and call it equivalent.
What's next for Agentic Bidding (Procurement)
Right now, only two of our agents — the ones that actually touch money and inventory — have their own locked-down identity. We want that for the whole fleet, not just those two. We'd also like the system to double-check pricing right before an order goes out, so a long wait for approval can't end with us paying against a quote that's already gone stale. If we get broader access to Model Armor and the Agent Gateway down the line, we'd swap our own guardrail and routing logic for the managed versions instead of maintaining our own. And the bigger goal: prove this isn't just a laptop-ordering tool. The same pattern — watch inventory, source, bid, get a human's yes — should work for any category of spend, in any department, not just IT hardware.
