Assemble: Turning an Enterprise Agent Fleet into a Governed Workforce
Enterprise AI is heading toward a world where companies do not have one assistant. They have hundreds of specialist agents across finance, procurement, operations, service, compliance, and other functions.
That creates a problem that agent registries alone do not solve:
Which approved agents should be allowed to act together for this specific business outcome?
That is what we built with Assemble for Google’s All Things Agentic Hackathon, in the Fortified Enterprise Fleet track.
This article was created for the purposes of entering the All Things Agentic Hackathon.
The idea
A registry can tell an enterprise which agents exist.
Assemble decides which of them may be appointed to a Mission, what authority they hold together, and what independently proves what happened.
The core principle is simple:
A Mission determines the organisation.
Instead of starting with a fixed multi-agent roster, the operator starts with a business outcome.
For our demo:
Chase overdue invoice 900100000004
Assemble then forms the organisation required to carry that Mission.
- FORM — Turn the outcome into a team
The operator states one business outcome.
Gemini 3.5 Flash on Vertex AI compiles the intent into a typed Mission Contract.
Google Agent Registry over MCP supplies the approved workforce.
Deterministic eligibility runs before ranking.
A capable specialist can still be refused because it is wrong for the Mission.
Four exact specialists are appointed:
Investigator
Communication
SAP Writer
Independent Verifier
The appointed team is persisted as a Frozen Assembly before execution begins.
The important distinction is:
Agent Registry tells the enterprise who exists. Assemble decides who gets appointed.
- TALK — Represent one institution to the customer
The external counterparty should not have to understand our internal agent roster.
They get one invitation, one room, and one thread.
AgentMail carries the invitation.
Gemini Live powers the Voice Room.
Model Armor screens the untrusted turn path.
The Communication specialist speaks because it was appointed to represent the institution.
Exact terms are restated before acknowledgement.
The customer meets one institution, not four internal agents.
- CONTINUE — Let the operator leave
The operator should not have to carry the work from one specialist to another.
After acknowledgement:
Cloud Tasks creates the durable async hand-off.
Cloud Run receives the later execution.
The same Frozen Assembly is reconstructed from durable state.
Google ADK executes the appointed roles.
Firestore holds authoritative Mission state.
Agent Engine Sessions and Memory Bank provide continuity and context.
The rule here matters:
Memory is context, not enterprise truth.
A remembered preference can influence how a conversation starts. It cannot become an invoice amount, payment date, or enterprise fact.
- ACT & VERIFY — Change SAP, then check it independently
The Writer records the Promise-to-Pay through the narrow SAP MCP → SAP S/4HANA boundary.
Then a different Verifier authority reads the enterprise state back.
The Writer acts. The Verifier reads back.
A worker returning success: true is not sufficient.
We also tested the boundary negatively:
Writer attempted a read → PRINCIPAL_NOT_PERMITTED
Verifier attempted a write → PRINCIPAL_NOT_PERMITTED
The actor cannot award itself success.
- SETTLE — Finish the Mission without inventing business success
Our final screen deliberately shows two answers:
MISSION WON
CASE OPEN
The bounded work succeeded.
The invoice is still unpaid.
The work completed. The business problem did not.
A promise is not a payment.
That distinction matters because autonomous systems should report progress without manufacturing business success.
Why this fits Fortified Enterprise Fleet
The track focuses on corporate agent discovery, multi-agent orchestration, long-term state, runtime observability, and security posture enforcement.
Assemble maps directly to those requirements:
Discovery: Google Agent Registry
Mission-specific orchestration: Frozen Assembly + Google ADK
Long-running execution: Cloud Tasks + Cloud Run
Durable state: Firestore
Persistent context: Agent Engine Sessions + Memory Bank
External interaction: AgentMail + Gemini Live
Security posture: eligibility, ToolAuthority, Model Armor, SAP MCP boundaries
Observability: Cloud Trace + evidence projections
Enterprise action: SAP S/4HANA
The larger idea is:
Assemble turns a registered enterprise agent fleet into a Mission-specific, governed workforce that can continue without the operator and prove what it actually did.
What we learned
The hardest part of enterprise agents is not getting an agent to act.
It is keeping institutional authority separate from model confidence.
A few lessons became central to the architecture:
Eligibility must happen before ranking.
Refusal is a feature.
Memory is context, not enterprise truth.
The actor should not grade its own work.
Historical appointments must remain historical.
One of the most useful lessons from our own red-team audit was:
A field called VERIFIED is not proof that verification happened.
What’s next: Graphs and bounded loops
Today, Assemble forms and governs the organisation for one Mission.
The next step is to let a larger business Case decompose into a graph of dependent Missions.
An edge should exist only when downstream work genuinely consumes an upstream result.
Then bounded loops can handle repair:
produce → check → correct → re-check
Rather than replaying an entire workflow, the system should repair only what failed.
The roadmap model becomes:
Graphs decide what depends on what.
Assemble decides who may act.
Loops decide what must be corrected.
Evidence decides when the loop can stop.
That graph-and-loop layer is roadmap work, not part of the submitted Golden Mission.
Links
Demo video:
https://www.youtube.com/watch?v=OjNn-Hr1Cn0
Live site:
https://assemble-control-plane-elhrkr6wkq-ew.a.run.app/
Live Command surface:
https://assemble-control-plane-elhrkr6wkq-ew.a.run.app/command
Architecture pack:
https://assemble-control-plane-elhrkr6wkq-ew.a.run.app/evidence/docs/architecture/assemble-final-architecture.pdf
Devpost:
https://devpost.com/software/assemble-outcome-driven-staffing-for-enterprise-agents
AllThingsAgenticHackathon #GoogleCloud #Gemini #AI #Agents #AgenticAI
For X, I’d post this as the main version:
Enterprises are about to have hundreds of AI agents.
A registry tells you who exists.
But who should be allowed to act together for this business outcome?
I built Assemble for Google’s #AllThingsAgenticHackathon.
One Mission:
Chase overdue invoice 900100000004
Assemble:
→ discovers the agent workforce
→ refuses ineligible specialists before ranking
→ appoints the exact team
→ freezes their authority
→ lets the operator walk away
→ records the action in SAP
→ has a different authority verify it
Final state:
MISSION WON
CASE OPEN
A promise recorded is not a payment cleared.
Demo: https://www.youtube.com/watch?v=OjNn-Hr1Cn0
Devpost: https://devpost.com/software/assemble-outcome-driven-staffing-for-enterprise-agents
Built with Gemini 3.5 Flash, Google ADK, Agent Registry, Cloud Run, Cloud Tasks, Firestore, Memory Bank, Model Armor, Cloud Trace and SAP MCP.
Next: graphs for dependency structure, bounded loops for repair.
Graphs decide what depends on what. Assemble decides who may act. Evidence decides when the loop can stop.
And if you want the stronger, shorter X version:
A registry tells an enterprise which AI agents exist.
Assemble decides which may be deputized for this Mission.
7 considered → 1 refused before ranking → 4 appointed → frozen.
The operator leaves.
The team continues.
The Writer changes SAP.
A different Verifier reads it back.
MISSION WON. CASE OPEN.
Built for Google’s #AllThingsAgenticHackathon, Fortified Enterprise Fleet.
Demo: https://www.youtube.com/watch?v=OjNn-Hr1Cn0
Devpost: https://devpost.com/software/assemble-outcome-driven-staffing-for-enterprise-agents
