Kiro Agent Orchestration Patterns

Building Event-Driven Multi-Agent Systems (or: How I Built 4 Apps Instead of 1 for a Hackathon)

So here’s the thing – everyone builds one app for hackathons, right? I built four. Not because I’m trying to show off but because… well, actually maybe a little bit of showing off, but mostly because exploring Kiro meant building multiple things and I wanted to really push what’s possible with event-driven architectures.

You can’t vibe code this kind of magic.

The Problem with Traditional Multi-Agent Systems

Look, I’ve been in the trenches. Seen teams of 10+ engineers with 10+ million in funding build these monolithic agent systems that basically… don’t work. They couple everything together, agents stepping on each other’s toes, no clear orchestration pattern. It’s a mess. And then they wonder why their funded startup dies without finding product-market fit.

The traditional approach? You’ve got your agents all talking directly to each other, sharing state, blocking on responses… it’s basically spaghetti code but with AI. No wonder these systems fall apart under load.

Enter Event-Driven Architecture (The Good Stuff)

So for FinAgent2 (yeah, creative naming, I know), I went full event-driven with the Motia framework. This is where it gets interesting…

Instead of agents calling each other directly, everything flows through events. Market data comes in? That’s an event. User asks a question? Event. Agent finishes analysis? You guessed it – event.

// This is how we used to do it (gross)
const result = await marketAgent.analyze(data);
const enriched = await sentimentAgent.enrich(result);
const final = await portfolioAgent.optimize(enriched);

// vs event-driven (chef's kiss)
emit('market.data.received', data);
// agents just listen and react independently

The beauty is each agent just listens for events it cares about. No direct dependencies. No blocking. Just pure, beautiful decoupling.

The Multi-Agent Orchestra

Here’s where Mastra comes in – and honestly, this framework is underrated. While everyone’s building custom agent orchestration (guilty as charged in FinAgent1), Mastra gives you this out of the box:

  • MarketAnalyst Agent: Listens for market events, emits analysis events
  • Risk Manager: Subscribes to portfolio changes, publishes risk assessments
  • Sentiment Tracker: Monitors news events, broadcasts sentiment scores
  • Portfolio Optimizer: Reacts to all the above, suggests rebalancing
  • Research Agent: Deep dives on demand, async results
  • Options Strategist: Complex derivatives stuff that honestly most users won’t use but looks impressive in demos

The kicker? Each agent has its own memory through Mem0 integration. So your sentiment agent remembers what it analyzed yesterday without polluting the portfolio agent’s context. Clean separation of concerns.

Why Event-Driven Beats Microservices (Fight Me)

OK so I also built a microservices version (FinAgent1) with 8+ containers because… well, because I could. But here’s the dirty secret nobody talks about:

Microservices are often overkill. There, I said it.

The event-driven version with Motia? Two containers. TWO. vs eight. Same functionality, 75% less operational complexity. Azure bills are basically nothing comparatively.

# Microservices approach (why did we do this to ourselves?)
services:
  api-gateway: ...
  market-service: ...
  sentiment-service: ...
  portfolio-service: ...
  research-service: ...
  oracle-service: ...
  # ... and on and on

# Event-driven (this is the way)
services:
  app:
    - All agents in one process
    - Event bus handles orchestration
  redis:
    - Events, caching, pub/sub

The Real Implementation Details

So Motia gives you these “steps” – think of them like workflow stages but async and event-triggered. Each step can spawn multiple agent actions:

const analyzeTrade = step({
  trigger: 'trade.requested',
  agents: [marketAnalyst, riskManager, sentimentTracker],
  aggregate: results => {
    // combine all agent outputs
    return consensus(results);
  }
});

The agents don’t know about each other. They just know about events. marketAnalyst sees “trade.requested” and starts analyzing. Risk manager does its thing. Sentiment tracker checks the vibes. All in parallel, all independent.

And here’s the thing that really makes this work – event replay. System crashes? Replay the events. Need to debug? Replay with logging. Want to backtest? Just replay historical events through the same system. It’s basically event sourcing but without the enterprise Java nightmares.

Challenges (Because Nothing Ever Just Works)

Azure App Service doesn’t like WebSockets. Or rather, it does, but only sometimes, and never when you’re demoing. So we built this hybrid streaming thing:

// Had to get creative here
const stream = isAzureBeingDifficult() 
  ? new PollingFallback('/api/events', 1000)
  : new EventSource('/api/stream');

Also, Motia’s documentation is… let’s call it “emerging”. Spent a lot of time reading source code. Actually contributed some fixes back because opensource karma and all that.

Memory management with multiple agents gets weird. Each agent maintaining context means memory usage can spiral. Implemented aggressive cleanup:

// Learned this the hard way at 3am
afterEach(event => {
  if (context.memoryUsage > threshold) {
    context.trimOldestEvents();
  }
});

What Actually Shipped

Both systems are live on Azure right now. The event-driven one is handling real market data from Alpaca, processing complex multi-agent workflows, and actually providing useful analysis. Response times under 200ms for most queries, scaling horizontally when needed.

The UI doesn’t look like every other Bootstrap financial app (you know the ones). TradingView charts for the professionals, clean interfaces that actually make sense. Though honestly, the second version lets users build their own UI entirely because… composability over features.

Lessons Learned (The Real Ones)

  1. Event-driven > microservices for 90% of use cases – Unless you’re Netflix, you probably don’t need 50 microservices

  2. Frameworks matter – Motia and Mastra saved literally months of work. Don’t rebuild what’s been solved.

  3. Cloud credits drive architecture – We’re on Azure because they gave us thousands in credits. AWS gave us like $200. Architecture follows incentives.

  4. Multi-agent orchestration is about coordination, not control – Let agents be autonomous, coordinate through events, not commands

  5. Memory persistence is crucial – Agents without memory are just stateless functions. Mem0 integration was a game-changer.

What’s Next

Honestly? Open-sourcing the whole thing. Too many closed-source “revolutionary” fintech platforms that die in obscurity. Let the community build on this.

Want to add more event types – market crashes, regulatory changes, whale movements. The architecture supports it, just need to implement the handlers.

Backtesting through event replay is basically already there, just needs a UI. Imagine replaying 2008 through your agent system… actually, that might be depressing.

The Bottom Line

Built four production apps for a hackathon because one felt boring. The event-driven multi-agent system with Motia/Mastra is legitimately better than what I’ve seen funded teams produce. It’s running, it’s scaling, and it actually works.

The vibes? They’re event-driven, asynchronously processed, and horizontally scalable.

P.S. – If you’re still building synchronous agent systems in 2025, we need to talk. Seriously.

P.P.S. – Yes, I know microservices have their place. But that place is not your MVP.

Similar Posts