1 comments

  • koke_vidaurre a day ago

      The problem:
    
      One AI agent is easy. But when you have 10 Claude sessions running — one researching, one writing, one monitoring costs — they need shared state. Otherwise they overwrite each other, duplicate work, or have no idea what the others did.
    
      What it does:
    
      squads status              # What's running across all sessions
      squads dash                # Full dashboard: costs, memory, activity
      squads run marketing/seo   # Execute an agent
      squads memory query "competitors"  # Search across all agent memory
      squads trigger sync        # Push trigger conditions to Postgres
    
      Architecture:
    
      Agents     = Markdown files (.agents/squads/*.md)
      Memory     = Postgres (persists across sessions)
      Sessions   = Redis (coordination, locks)
      Costs      = OpenTelemetry (what each run cost)
      Bridge     = Syncs MD ↔ services
    
      The vision:
    
      A BI tool for AI agents. Everyone's shipping agents, but nobody can answer: what ran, what it cost, whether it worked. We want to fix that.
    
      Agents are the new microservices. And just like microservices needed observability (Datadog, Grafana), agents need it too.
    
      Where we are:
    
      -  Dogfooding daily — runs our 16-squad setup
      -  Parallel session coordination solved
      -  Full cost tracking via OpenTelemetry
      -  Smart triggers (fire agents based on SQL conditions)
      -  Dashboard UI in progress
    
      Results:
    
      10x GitHub contributions since adopting this workflow. Verifiable on my profile.
    
      Opinionated choices:
    
      - Claude Code as execution runtime (our stack)
      - Local-first (Postgres/Redis on your machine)
      - Markdown prompts over framework abstractions
      - Git-friendly (everything diffable)
    
      Code: https://github.com/agents-squads/squads-cli
    
      Happy to answer questions about the architecture or what we learned building it.