Hi, DEV đź‘‹
I'm part of the team building Cartha — an ops layer for AI agents that actually run in production.
This is a short intro: the problem we kept hitting, what we shipped, and what I'll write about here.
The problem
We were debugging an agent that did something inexplicable in production. Logs and traces answered what ran. They didn't answer the question that mattered:
What did the agent know when it made that call — and was it allowed to know that?
If you run multi-agent systems, you eventually need more than a pretty timeline:
| Need | Why it matters |
|---|---|
| Scoped memory | User vs agent vs team vs org — without leaks |
| Hard budgets | Soft alerts don't stop a retry loop at 3am |
| Tool limits | Child agents shouldn't inherit the keys to the kingdom |
| HITL | Some actions need a human before they execute |
Observability tells you what happened. Governance decides what is allowed to happen next.
What Cartha is
Not a chatbot builder. You keep your own agents (OpenAI, tools, business logic).
Yes a control plane for fleets:
- Run timelines (tools + LLM steps)
- Server-enforced memory scopes (
user/agent/team/org) - Fail-closed spend budgets on a run
- Nested agents + attenuated delegation
- Policies + escalations
- Dashboard for agents, traces, cost, memory
Minimal Python path
python
import cartha
cartha.init() # CARTHA_API_KEY + CARTHA_API_BASE=https://cartha.in
client = cartha.wrap_openai() # auto LLM steps + cost
@cartha.tool()
def crm_lookup(user_id: str) -> dict:
return {"plan": "pro"}
@cartha.trace(id="support", team="support", budget_usd=0.5)
def handle(user_id: str, ticket: str) -> str:
data = crm_lookup(user_id)
r = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": f"{ticket}\n{data}"}],
)
return r.choices[0].message.content or ""
Docs: How to Use (https://cartha.in/how-to-use)
Product: cartha.in (https://cartha.in)
Top comments (3)
Agent fleets make ops visible fast. Once there are multiple workers, the hard part becomes routing, shared memory, permission boundaries, and knowing which agent owns the next step. The fleet needs operations design as much as prompting.
Exactly this.
Prompting gets the first agent working. A fleet makes the system visible: who can see which memory, who is allowed to call which tool, how work is handed off, and who owns the next step when three agents are mid-flight.
That’s the gap we’re building for with Cartha, not “better chat,” but ops for multi-agent systems: scoped memory (enforced, not “trust the prompt”), traces across nest/delegation, hard spend caps, and policy boundaries so a child agent can’t inherit more authority than the parent.
The mental model that helped us: treat the fleet like a small distributed system. You need routing + ownership + permissions + observability. Prompting is the application code; operations design is the runtime.
Curious how you’re handling shared memory and handoffs today, app level conventions, or something in the platform?
That distributed-system frame is the right one. The moment agents can delegate, spend, remember, or call tools independently, the product stops being a chat surface and starts needing ops primitives: ownership, traceability, scoped authority, and a clean way to recover when the handoff goes wrong.