Back to Blog

Building in Public: The v0.8 to v0.9.1 Chapter

May 5, 2026•Soorma Team

When we published the v0.7 build-in-public post in January, Soorma had event-driven choreography and working memory. It was learnable and prototypable, but the higher-level abstractions weren't there yet. If you wanted to orchestrate multiple agents, you were doing it by hand.

v0.9.1 closes that gap. Here is what shipped.

What Changed

The Planner Component

v0.7 had Workers and Tools, but no first-class Planner. Strategic orchestration — deciding which tasks to emit, in what order, with what coordination — was left to users to implement on top of raw event publishing.

v0.9.1 ships the Planner class: a component with on_event handlers that reasons over business events and emits structured task events to Workers. The key constraint is explicit response_event on every task emission — no inferred event names, no implicit routing. Every Planner-to-Worker contract is declared in code and recorded in the Registry.

See Inside the Planner for the full mechanics.

Tracker Service

Observability was the biggest gap in v0.7. You could see events flowing through NATS, but you had no structured view of plan state — which tasks were running, which had completed, which had failed.

The Tracker service, shipped in v0.9.1, records every plan as a state machine. It observes the response_event and correlation_id chain automatically — no explicit write API needed. context.tracker.get_plan_progress(), get_plan_tasks(), and get_plan_timeline() give you structured visibility into multi-agent orchestration without instrumenting your agent code beyond the PlatformContext calls you are already making.

See Tracker Observability for the full API.

Schema Registry and Service Discovery

The Registry in v0.7 was a simple capability store. In v0.9.1 it also stores event schemas — the events_consumed and events_produced contracts declared when an agent registers. This enables gateway-level payload validation before events reach agent handlers, and gives Planners a programmatic way to discover Workers by capability before emitting tasks.

See Service Discovery and the Schema Registry for the full picture.

The Two-Layer SDK

The most significant architectural change is one you might not see directly in your agent code — which is the point.

Before v0.9.1, examples and integrations sometimes reached directly into service clients. In v0.9.1, the SDK enforces a strict two-layer architecture: agent code uses context.memory, context.bus, context.registry, and context.tracker exclusively. Service clients are internal. The PlatformContext object is the only surface your handlers should touch.

This means your agent code is decoupled from every service boundary decision — transport, auth, tenant isolation, retry logic. The platform handles all of it before it reaches your handler. See ARCHITECTURE_PATTERNS.md Section 2 for the full specification.

What Is Still Ahead

v0.9.1 is a strong foundation for local development and prototyping. A few things are still in progress:

  • Architecture enhancements — we are actively working on making it easier to model workflows and semantic context directly into agents. The goal is to reduce the boilerplate needed to express orchestration intent and memory structure, so the code more closely mirrors how you think about the problem. More on this when it is ready to share.
  • Production SLAs — the current release is suitable for learning and development; production hardening targets v1
  • Self-hosted infrastructure blueprints — Terraform modules for your own VPC are coming with v1
  • Managed cloud deployment — soorma deploy to a hosted control plane is on the roadmap but not yet available

We will continue building in public. The CHANGELOG has the full version history, and the examples directory has runnable code for every pattern covered in this series.

Getting Started

Start with the hello-world example, then work through the learning path. If something is unclear or broken, open an issue — this is still active development and your feedback directly shapes what ships next.

If you find Soorma useful or want to follow along as we build, star the repo — it helps us understand who is watching and keeps the project visible.