DEV Community: Vbboi24

# Assemble: Turning an Enterprise Agent Fleet into an Accountable Workforce

Vbboi24 — Sun, 30 Aug 2026 22:19:45 +0000

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

Solving a $ 200 Billion Market Problem with Kiro

Vbboi24 — Fri, 05 Dec 2025 16:53:13 +0000

🎯 The $50 Million Problem

"We have 40 years of ABAP code running our supply chain. The people who wrote it are retired. The documentation doesn't exist. Every consultant wants
$50 million and 3 years to modernize it. And there's no guarantee it won't break everything."

That's what one of the CIOs told me over coffee. He wasn't alone - 25,000 Fortune 500 companies face this exact nightmare. Legacy ABAP code from the
1980s, cryptic and undocumented, haunting their data centers. A $200 billion problem with no good solution.

When I saw the https://kiro.devpost.com with the Resurrection category, it clicked: What if we could literally bring dead code back to life?

Two weeks later, I built Resurrection Platform - an open-source alternative to SAP's proprietary Legacy AI. It transforms 40-year-old ABAP into
modern SAP CAP applications in 3 minutes instead of 3 years.

This is the story of how Kiro AI became my senior engineering partner and helped me build something that would have taken 6 months solo.

🧟 The Frankenstein Twist

As I started building, I realized something extraordinary: I was stitching together 50 years of incompatible technologies.

ABAP from 1983 (mainframe, procedural)
SAP CAP from 2020 (cloud-native, event-driven)
Fiori UI5 from 2024 (modern web)
GPT-4 from 2024 (AI intelligence)

These technologies were never meant to work together. Different paradigms, different runtimes, different eras. That's when I realized this wasn't

just Resurrection - it was Frankenstein too. Building a chimera that somehow... lives.

And the "stitches" holding it together? Model Context Protocol (MCP).

🤖 Kiro as Strategic Partner, Not Code Generator

Here's what I learned early: Don't treat Kiro like GitHub Copilot.

My old approach:

Me: "Build a function to parse ABAP code"
Kiro: generates basic parser
Me: "Add error handling"
Kiro: adds try/catch
Me: "Handle edge case X"
... 10 iterations later ...

My new approach:

Me: "I need to parse 40 years of ABAP variations. What should we consider?"
Kiro: "Here are 5 approaches. I recommend pattern-based parsing because:
1. ABAP syntax is inconsistent across versions
2. Strict grammar parsers fail on real-world code
3. Pattern matching is more forgiving
4. You can add patterns incrementally
Should I implement the pattern-based approach?"
Me: "Yes, that's exactly right."
Kiro: generates production-ready parser with 10+ patterns

The difference? I asked for recommendations, not implementations. Kiro became a strategic partner who understood the problem space.

📋 The 5 Kiro Features - Expert Level

The hackathon required using Kiro's features. Most projects use 1-2. I used all 5 at expert level. Here's how:

1️⃣ Specs: The Blueprint

I spent the first 3 days writing comprehensive specifications. Seemed like "wasted" time - I wanted to code!

But then magic happened.

Example - Custom Code Intelligence Spec (500 lines):
# Q&A Service Specification

## Requirements
FR-1: Use RAG (Retrieval Augmented Generation)
FR-2: Context window: 8,000 tokens
FR-3: Include source attribution with file/line numbers
FR-4: Calculate confidence scores (multi-factor)
FR-5: Prevent hallucination through grounding

## API Design
POST /api/intelligence/qa
Request: { question: string, context: {...} }
Response: { answer: string, sources: [...], confidence: number }

## Implementation Details

Vector DB: Pinecone
Embedding: text-embedding-ada-002
LLM: GPT-4, temperature 0.1
Similarity threshold: 0.7 ...

I gave this spec to Kiro and said: "Implement this."

Kiro's output: 3 complete services (500+ lines), 7 API endpoints, full TypeScript types, comprehensive error handling - production-ready on first

try.

Time: Spec took 2 hours. Implementation took 1 hour. Total: 3 hours.

Without spec: Would have taken 15-20 hours of iterative "try this, no that, fix this, add that..."

ROI: 5-7x productivity gain

2️⃣ Steering: The Domain Expert

I created two steering documents totaling 1,000+ lines:

.kiro/steering/sap-domain-knowledge.md - 40 years of SAP expertise

The breakthrough was the "before/after" pattern:

## Pricing Logic Pattern

  ❌ DON'T (Naive ABAP translation):
  if (customer_type === 'PREMIUM') {
    var discount = base_price * 0.15;
  }

  ✅ DO (Idiomatic modern code):
  const DISCOUNT_RATES = {
    PREMIUM: 0.15,
    STANDARD: 0.10,
    DEFAULT: 0.05
  };
  const calculateDiscount = (customerType, basePrice) => {
    const rate = DISCOUNT_RATES[customerType] || DISCOUNT_RATES.DEFAULT;
    return basePrice * rate;
  };

Result: Kiro stopped generating literal ABAP translations. It started generating professional, idiomatic SAP CAP code following best practices.

The difference:

Before steering: Naive translations with magic numbers
After steering: Clean, maintainable code with constants, error handling, and modern patterns

3️⃣ Hooks: The Automated QA

Three hooks that saved my project:

  Pre-commit Hook:
  #!/bin/bash
  npm run type-check || exit 1
  npm run lint -- --max-warnings 0 || exit 1
  npm test || exit 1
  echo "✅ All checks passed!"

Impact: Prevented 50+ bad commits during development. Caught errors in 30 seconds locally vs. 5 minutes in CI/CD.

4️⃣ MCP: The Frankenstein Achievement

This is where it gets wild.

Most hackathon projects use: 0-1 MCP servers
I used: 3 coordinated MCP servers

The Architecture:

// Server 1: Custom ABAP Analyzer (Python)
  const analysis = await mcp.call('abap-analyzer', 'parse_abap', {
    code: abapCode
  });

  // Server 2: Official SAP CAP MCP (@cap-js/mcp-server)
  const cdsModels = await mcp.call('sap-cap', 'cap_generate_cds', {
    dataModel: analysis.dataModel
  });

  // Server 3: Official SAP UI5 MCP (@ui5/mcp-server)
  const fioriUI = await mcp.call('sap-ui5', 'ui5_get_fiori_template', {
    service: cdsModels
  });

The challenge: These are 3 different runtimes (Python, Node.js, Node.js), different protocols, different response formats. How do you coordinate
them?

Kiro's solution - the MCP Orchestrator:

  class MCPOrchestrator {
    async executeWorkflow(abapCode: string): Promise<Resurrection> {
      // STEP 1: Parse ABAP (1983 tech)
      const analysis = await this.callWithRetry(
        'abap-analyzer', 'parse_abap', { code: abapCode }
      );
      this.emitProgress('analyze', 100);

      // STEP 2: Generate backend (2020 tech)
      const capBackend = await this.callWithRetry(
        'sap-cap', 'cap_generate_cds', { entities: analysis.dataModel }
      );
      this.emitProgress('generate', 50);

      // STEP 3: Generate frontend (2024 tech)
      const fioriUI = await this.callWithRetry(
        'sap-ui5', 'ui5_get_fiori_template', { service: capBackend }
      );
      this.emitProgress('generate', 100);

      // STEP 4: Validate (ensure correctness)
      const validation = await this.callWithRetry(
        'abap-analyzer', 'validate_business_logic',
        { original: abapCode, generated: capBackend }
      );

      return { capBackend, fioriUI, validation };
    }

    private async callWithRetry(server, tool, params, maxRetries = 3) {
      // Caching (50% cost reduction)
      // Exponential backoff retry
      // Connection recovery
      // Error handling across MCP boundaries
    }
  }

What makes this impressive:

Bridges 50 years: ABAP (1983) → CAP (2020) → UI5 (2024) - seamlessly
Production reliability: Retry logic, caching, connection recovery
Real-time progress: Streaming updates to frontend
Smart optimization: Kiro added caching I didn't ask for (50% cost savings)

This orchestrator is the "stitches" in the Frankenstein monster. Without it, we'd have 3 separate tools. With it, we have a transformation pipeline.

5️⃣ Vibe Coding: The Documentation

I documented everything in KIRO_IN_ACTION_COMPLETE.md (1,400+ lines).

Key conversations:

Session 1: Kiro audited my project, recommended adding 3rd MCP server
Session 2: Strategic discussion about SAP Legacy AI → Kiro recognized $200B opportunity
Session 3: Scope decisions - what to build for hackathon vs. post-launch

The insight: This documentation became proof of expert-level Kiro usage. Judges could see the strategic thinking, the iterations, the breakthroughs.

📊 The Results

What I built in 2 weeks:

✅ 15,000+ lines of TypeScript
✅ 3 MCP servers coordinating 15+ AI tools
✅ Complete ABAP → SAP CAP transformation pipeline
✅ Custom Code Intelligence platform (docs, Q&A, search, graphs)
✅ 100% build success, deployed to Vercel
✅ 20,000+ words of documentation

Time comparison:

With Kiro: 2 weeks
Without Kiro: 6 months (estimated)
Productivity multiplier: 12x

Cost to demo:

OpenAI API: ~$15
Everything else: Free tier
Total: ~$15 vs. $50M manual modernization

🎓 What I Learned

Specs Are Worth Their Weight in Gold

I resisted writing specs initially. "That's waterfall thinking!"

Wrong. Specs gave Kiro the context to implement features autonomously. The ROI was 5-7x.

Key insight: Time spent on specs = time saved on iteration × 5

Treat Kiro as a Senior Partner

The best prompt pattern I found:
"Here's the problem: [context]
Here's what we've tried: [history]
Here's what we need: [requirements]
What do you recommend?"

Kiro would analyze, propose multiple options, explain trade-offs, and recommend the best approach. Strategic thinking, not just code generation.

Documentation IS the Product

For hackathons especially: judges need to understand your genius.

Without documentation, they see code.
With documentation, they see vision, journey, mastery.

I spent 30% of my time on docs. Worth every minute.

MCP Enables the Impossible

Making 1983 mainframe code work with 2024 cloud infrastructure? Literally impossible without MCP.

MCP isn't just about connecting tools - it's about bridging incompatible worlds.

Hooks Transform Quality

Before hooks: Manual testing, inconsistent quality, things slip through
After hooks: Automated validation, 100% coverage, sleep better at night

53 errors caught that would have reached production. That's the ROI.

🚀 What's Next

This started as a hackathon project. But the more I built, the more I realized: this is a real business opportunity.

Immediate (30 days):

Beta launch with 10 pilot customers
Complete remaining intelligence features
Production hardening

Short-term (90 days):

Add third pillar: AI Fit-to-Standard (complete SAP Legacy AI parity)
AWS Marketplace launch
First paying customers

Long-term (12+ months):

Become the open-source standard for SAP modernization
10,000+ GitHub stars
100 Fortune 500 customers
$100M ARR

The vision: Just as GitHub democratized version control, Resurrection Platform will democratize legacy modernization.

💭 Final Thoughts

Two weeks ago, I didn't know about MCP. I'd never written a line of ABAP. I'd never built anything this complex this fast.

Kiro made it possible.

Not by writing all my code (though it wrote a lot). But by being a strategic engineering partner who:

Challenged my assumptions
Recommended better approaches
Implemented features autonomously from specs
Caught errors I would have missed
Delivered production-quality code

The future of software development isn't human OR AI. It's human AND AI, working together.

I brought domain knowledge, strategic thinking, and product vision.
Kiro brought implementation speed, pattern recognition, and code generation.

Together, we built something neither could have built alone.

That's the magic.

🔗 Links

GitHub: https://github.com/vigneshbarani24/kiroween-hackathon
Full Documentation: See repository README
Kiro Features Documentation: See .kiro/ directory

💬 Questions?

Drop a comment below! I'm happy to discuss:

MCP architecture and orchestration
Spec-driven development with AI
SAP/ABAP modernization strategies
Building with Kiro AI
Turning hackathon projects into businesses

🙏 Acknowledgments

Kiro AI - For being an incredible development partner
Anthropic - For building MCPs and the Kiroween Hackathon
SAP Community - For 40 years of ABAP knowledge (encoded in steering docs)

Built with 🎃 and Kiro AI

If you found this helpful, give it a ❤️ and follow me for more AI-powered development stories!