{"id":12823,"date":"2026-02-19T12:49:22","date_gmt":"2026-02-19T12:49:22","guid":{"rendered":"https:\/\/www.castelis.com\/?p=12823"},"modified":"2026-02-23T09:57:02","modified_gmt":"2026-02-23T09:57:02","slug":"field-report-openclaw-multi-ai-agents","status":"publish","type":"post","link":"https:\/\/www.castelis.com\/en\/news\/custom-development\/field-report-openclaw-multi-ai-agents\/","title":{"rendered":"10 AI Agents, 4 Hours, $30: A Field Report on OpenClaw"},"content":{"rendered":"

How we had a team of 10 autonomous AI agents build an invoicing application \u2014 and what it changes for the future of software development<\/p>\n

The starting point<\/h2>\n

\u201cVibe coding\u201d, the practice of coding in free-form dialogue with an LLM, has obvious limitations. It works well for a script, an isolated component, or a quick prototype. But as soon as a project moves beyond the POC stage, the lack of structure becomes costly: loss of context, architectural inconsistencies, recurring bugs, and zero traceability.<\/p>\n

What if, instead of interacting with a single model, we had an entire team of specialized agents collaborate, each with its own role, memory, and responsibilities?<\/p>\n

That\u2019s the hypothesis we tested at Castelis by combining two open-source building blocks: OpenClaw<\/strong> for multi-agent orchestration, and prompts from the BMAD<\/strong> methodology to define our agents\u2019 roles.<\/p>\n

 <\/p>\n

The tools: OpenClaw and BMAD in a nutshell<\/h2>\n

What is OpenClaw?<\/h3>\n

OpenClaw is a self-hosted, open-source AI agent runtime. Concretely, it\u2019s a persistent Node.js service that runs on your server and exposes your agents via Telegram, WhatsApp, Discord, or web chat.<\/p>\n

Each agent has its own workspace (personality files, memory, tools), persistent sessions, and can communicate with other agents through an inter-agent messaging mechanism (sessions_send<\/code>).<\/p>\n

 <\/p>\n

BMAD (Breakthrough Method of Agile AI-Driven Development)<\/h3>\n

BMAD is a framework that defines agent roles modeled after a real agile team: analyst, product manager, architect, UX designer, developer, QA, scrum master, and ops.<\/p>\n

Each role is described in a Markdown file that serves both as a persona definition and as operational instructions.<\/p>\n

 <\/p>\n

Our hybrid approach<\/h2>\n

We did not use BMAD directly as a framework. Instead, we extracted its agent prompts and injected them into the SOUL.md<\/code> files of our OpenClaw agents.<\/p>\n

For example, the BMAD Analyst prompt became the foundation of the SOUL.md<\/code> for our OpenClaw agent Mary (analyst). This allowed us to benefit from BMAD\u2019s methodological rigor while leveraging OpenClaw\u2019s persistence and inter-agent communication.<\/p>\n

 <\/p>\n

The architecture: 10 agents, one orchestrator, zero vibe coding<\/h2>\n

We deployed 10 agents on a minimal Debian server (2 vCPU, 2 GB RAM) with Nginx as a reverse proxy and Let\u2019s Encrypt for SSL. Infrastructure cost: close to zero.<\/p>\n

Each agent has a clear identity, a precise role, and persistent memory:<\/p>\n

    \n
  • \n

    The Pilot<\/strong> (orchestrator) assigns tasks, tracks progress, and maintains the global project context. It doesn\u2019t code or design, it coordinates.<\/p>\n<\/li>\n

  • \n

    Mary<\/strong> (analyst) produces business briefs.<\/p>\n<\/li>\n

  • \n

    John<\/strong> (PM) writes PRDs, epics, and stories.<\/p>\n<\/li>\n

  • \n

    Winston<\/strong> (architect) defines the technical architecture and ADRs.<\/p>\n<\/li>\n

  • \n

    Sally<\/strong> (UX) and Lena<\/strong> (UI) handle user experience specifications and visual identity respectively.<\/p>\n<\/li>\n

  • \n

    Bob<\/strong> (scrum master) manages sprint planning.<\/p>\n<\/li>\n

  • \n

    Amelia<\/strong> (dev) implements the code and pushes to GitHub via a configured SSH key.<\/p>\n<\/li>\n

  • \n

    Quinn<\/strong> (QA) tests and validates.<\/p>\n<\/li>\n

  • \n

    Oscar<\/strong> (ops) handles deployment and server security.<\/p>\n<\/li>\n<\/ul>\n

    The entire system follows the BMAD pipeline across four phases: Analysis, Planning, Solutioning, Implementation<\/strong>.<\/p>\n

    Each agent receives tasks with a standardized context block (project, slug, path, current phase), and all produced artifacts are stored in a shared file structure through project-context.md<\/code>.<\/p>\n

    \"Openclaw<\/p>\n

     <\/p>\n

    What worked<\/h2>\n

    The hub-and-spoke model holds up<\/h3>\n

    The Pilot orchestrates, agents execute, and context flows correctly between agents through shared files. Agents stay within their roles and produce artifacts in the right place.<\/p>\n

    Lateral communication feels natural<\/h3>\n

    Allowing agents to communicate directly, (for example: Amelia notifying Quinn that a release is ready or Quinn reporting a bug directly back to Amelia) reproduces real team dynamics.<\/p>\n

    The safeguard \u201cno re-delegation\u201d (an agent cannot delegate to a third party) prevents uncontrolled chains of delegation.<\/p>\n

    The QA workflow proved its value from day one<\/h3>\n

    Simple rule: no deployment without Quinn\u2019s validation.<\/p>\n

    As soon as this rule was enforced, production bugs dropped to zero. The QA agent caught issues the dev agent had missed, exactly as in a human team.<\/p>\n

    Persistent memory changes everything<\/h3>\n

    Each agent has its own MEMORY.md<\/code> and access to shared context files. Between sessions, an agent resumes exactly where it left off.<\/p>\n

    This is what differentiates this setup from simple prompt engineering: we move from ephemeral conversations to continuous collaboration.<\/p>\n

     <\/p>\n

    The pitfalls: what the documentation doesn\u2019t tell you<\/h2>\n

    The 30-second timeout is a silent killer<\/h3>\n

    This was the most insidious issue we encountered.<\/p>\n

    The default timeout for sessions_send<\/code> in OpenClaw is 30 seconds. Our agents regularly take longer than that to produce documents (briefs, PRDs, implementations).<\/p>\n

    When the timeout expires, the result is never saved in the session history. OpenClaw injects a synthetic error result, and the agent loses all the work it just produced. No visible error on the user side.<\/p>\n

    The fix: explicitly set timeoutSeconds<\/code> , minimum 180 seconds for standard tasks, 300 seconds for longer documents.<\/p>\n

     <\/p>\n

    Multi-agent documentation is incomplete<\/h3>\n

    We had to read OpenClaw\u2019s source code to understand that:<\/p>\n

      \n
    • \n

      tools.agentToAgent<\/code> must be explicitly enabled (disabled by default),<\/p>\n<\/li>\n

    • \n

      both agents (source and target) must be listed in an allowlist,<\/p>\n<\/li>\n

    • \n

      and the distinction between sessions_send<\/code> (A2A messaging with persona and memory) and sessions_spawn<\/code> (ephemeral sub-agent without context) is critical.<\/p>\n<\/li>\n<\/ul>\n

      We use sessions_send<\/code> exclusively.<\/p>\n

       <\/p>\n

      Context window management remains critical<\/h3>\n

      Workspace file size limits injected into the context cause silent truncations. The Pilot\u2019s MEMORY.md<\/code>, at 9,000 characters, exceeds the limit and gets truncated.<\/p>\n

      More fundamentally, agents eventually \u201cforget\u201d decisions made in previous sprints, leading to recurring bugs \u2014 typically deployment errors or regressions on previously validated architectural choices.<\/p>\n

      This is the single most critical optimization point for maintaining long-term project consistency.<\/p>\n

      \"Strenghts<\/p>\n

       <\/p>\n

      The numbers<\/h2>\n

      The first project, an invoicing application for small businesses and freelancers (Express.js + PostgreSQL backend, React + Vite frontend), was developed in roughly 4 hours of LLM usage for a total cost of $30<\/strong>.<\/p>\n

      The default model was Claude Haiku 4.5 for cost-efficiency, with occasional calls to Claude Opus 4.5 for complex tasks.<\/p>\n

      Nine stories were implemented in the first sprint: customer CRUD, invoice CRUD, PDF generation, and status management.<\/p>\n

      Let\u2019s be clear: the result is a functional POC demonstrating feasibility, not a production-ready product.<\/p>\n

      However, the cost-to-output ratio is remarkable and opens concrete opportunities for real-world projects.<\/p>\n

      Our recommendations going forward<\/h2>\n

      Adapt the number of agents to the context<\/h3>\n

      Ten agents are probably too many for most projects. Merging UX and UI, PM and Scrum Master, or combining roles depending on the phase, would reduce coordination overhead without sacrificing quality.<\/p>\n

      The ideal setup is not static. It should evolve with the project phase (initial development, debugging, feature expansion).<\/p>\n

      Define phase-specific workflows<\/h3>\n

      The linear Analysis \u2192 Planning \u2192 Solutioning \u2192 Implementation pipeline works well for initial development.<\/p>\n

      For debugging or feature additions, a lighter workflow with fewer agents and shorter feedback loops would be more efficient.<\/p>\n

      Treat agent documentation like code<\/h3>\n

      Any change to AGENTS.md<\/code>, TOOLS.md<\/code>, or SOUL.md<\/code> alters agent behavior.<\/p>\n

      It should be versioned in Git, reviewed, and deployed with the same rigor as application code.<\/p>\n

      Invest in memory management<\/h3>\n

      Break memory files into smaller chunks, implement periodic summarization mechanisms, and actively monitor context truncation.<\/p>\n

      This is the key to moving from POC to real project usage.<\/p>\n

       <\/p>\n

      Next steps: observability and scaling up<\/h2>\n

      Two improvement axes clearly emerge to move from POC to industrial-grade usage.<\/p>\n

      Add an LLM observability layer<\/h3>\n

      Today, our visibility into agent behavior is limited to OpenClaw gateway logs (14 MB per day of activity) and manual inspection of generated artifacts. That\u2019s insufficient at scale.<\/p>\n

      At Castelis, we already use Langfuse in production for LangChain-based AI projects. It\u2019s an open-source, self-hostable LLM observability platform that traces every LLM call (prompts, responses, token usage, latency), tracks costs in real time, and detects anomalies.<\/p>\n

      The natural next step is to extend this instrumentation to our OpenClaw multi-agent setup: trace inter-agent exchanges, measure consumption per agent and per project phase, identify looping agents or quality degradation.<\/p>\n

      In a system with 10 autonomous agents, this visibility isn\u2019t optional, it\u2019s a requirement for viability. Without it, you\u2019re flying blind.<\/p>\n

      Both communities are actively exploring OpenClaw\/Langfuse integration via OpenTelemetry, and a Langfuse maintainer is ready to release an official integration.<\/p>\n

      The convergence between multi-agent orchestration and LLM observability is no longer a matter of if<\/em>, but when<\/em>.<\/p>\n

       <\/p>\n

      Test more robust models than Haiku<\/h3>\n

      Our POC relied primarily on Claude Haiku 4.5, chosen for its cost-performance ratio. It\u2019s well-suited for repetitive, well-scoped tasks (CRUD operations, formatting, deployment).<\/p>\n

      But for high-complexity tasks, architecture analysis, subtle bug resolution, design decisions \u2014 its limits become apparent.<\/p>\n

      Recurring deployment errors were partly due to the model\u2019s reasoning limitations on multi-step problems.<\/p>\n

      The next step is to test a more granular routing strategy: lightweight models for execution tasks, more powerful models (Claude Sonnet 4.5 or Opus 4.6) for reasoning-heavy tasks.<\/p>\n

      The additional API cost would likely be offset by reduced time spent fixing avoidable errors.<\/p>\n

      What this signals for the software development lifecycle<\/h2>\n

      This experiment goes beyond a technical exercise. It illustrates a deeper evolution of the SDLC: moving from AI as a point-assistance tool (copilot, code completion) to AI as a team of autonomous agents executing an end-to-end engineering pipeline under human supervision.<\/p>\n

      Multi-agent AI isn\u2019t prompt engineering, it\u2019s systems engineering.<\/p>\n

      Configuration, timeouts, memory management, inter-agent coordination, these are infrastructure problems, not prompt problems. And that\u2019s precisely what makes the approach viable for organizations that require rigor, traceability, and reproducibility.<\/p>\n

      For companies, the question is no longer \u201cCan AI write code?\u201d but \u201cHow do we structure a team of AI agents to produce reliable, maintainable outcomes?\u201d<\/p>\n

      At Castelis, we\u2019re continuing to explore that question and the early results are promising.<\/p>\n","protected":false},"excerpt":{"rendered":"

      How we had a team of 10 autonomous AI agents build an invoicing application \u2014 and what it changes for the future of software development The starting point \u201cVibe coding\u201d, the practice of coding in free-form dialogue with an LLM, has obvious limitations. It works well for a script, an isolated component, or a quick […]<\/p>\n","protected":false},"author":26,"featured_media":12810,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"content-type":"","footnotes":""},"categories":[60,73],"tags":[],"class_list":["post-12823","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-custom-development","category-artificial-intelligence"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/posts\/12823","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/users\/26"}],"replies":[{"embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/comments?post=12823"}],"version-history":[{"count":5,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/posts\/12823\/revisions"}],"predecessor-version":[{"id":12850,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/posts\/12823\/revisions\/12850"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/media\/12810"}],"wp:attachment":[{"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/media?parent=12823"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/categories?post=12823"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.castelis.com\/en\/wp-json\/wp\/v2\/tags?post=12823"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}