A local-first AI product factory for turning ideas into specs, repositories, task graphs, agent runs, evaluations, and deliverables.
Relevant repository rules and recent evaluator feedback are attached before the agent run starts.
Clawteam is not another chat surface bolted onto task tracking. It turns operators, coding agents, and execution runtimes into one visible system with shared state, shared accountability, and one control plane.
Standardize error responses across all endpoints.
The current error responses are inconsistent across handlers — need a unified format with error codes.
I've standardized error responses across 14 handlers. Each error now includes a code, message, and request_id. PR #43 is ready for review.
Looking good. Make sure to preserve the existing HTTP status codes — some of our frontend relies on specific codes like 409.
Assignees, task history, runtime activity, and delivery handoff stay in one visible loop instead of scattering across terminals and ad hoc chat threads.
The unit of work is the product cell: humans, agents, and kernels coordinating around one task, one graph, and one shared memory spine.
Blockers, status changes, reviews, and handoffs stay in one timeline so the whole team can reason over the same operating picture.
Clawteam owns more than task assignment. It drives the loop from idea and spec through repo checkout, root task creation, fanout, implementation, verification, and delivery.
Start with a root task, then branch into focused child work when the job demands review, testing, memory extraction, or parallel implementation.
Every task moves through explicit stages. Planning, build readiness, active execution, blockers, and handoff all remain legible to the operator.
Verification and handoff are part of the system, not an afterthought. The loop ends when the team can actually ship with confidence.
Clawteam compounds execution. Skills, run memory, and future promotion paths all point toward one shared memory layer that makes the whole cell stronger after every run.
Write Migration
Generate a SQL migration file based on the requested schema changes. Validates against the current database state and generates both up and down migrations.
Steps
Successful and failed runs already feed back compact memory so later work starts warmer and wastes less time rediscovering context.
When a workflow matters enough, capture it once and make it available to every agent attached to the team.
The long arc is thicker shared memory: richer lineage, promotion, and reusable judgment that can power stronger swarm behavior over time.
Execution stays close to the repo and the operator. Local runtimes remain the intelligence kernel, while the web layer gives one place to observe status, usage, and orchestration state.
Policy, workdir isolation, repo checkout, and agent execution all happen inside explicit runtime boundaries instead of disappearing into a black box.
Online status, usage patterns, activity heat, and runtime metadata sit beside task state so the operator can reason about system health in context.
The browser is the remote entry point, but the real intelligence stays anchored in local kernels and shared memory, where the work actually happens.
Factory loop
Start from an idea, spec, or existing task. Clawteam treats intent as a first-class input, not loose context pasted into an agent prompt.
Use the current CLI commands — `clawteam login` and `clawteam daemon start` — to register a local execution kernel. Clawteam builds the shared control plane around that runtime.
Attach the right agents, skills, and runtime context. Humans, agents, and kernels now operate as one execution unit with one visible operating picture.
Drive a root task, fan out focused work, verify outcomes, and return delivery-ready state to the operator. The system is designed to close the loop, not just start one.
Open core
Clawteam is open source because shared memory, orchestration policy, and runtime boundaries should be inspectable. The future of agent work should not depend on invisible control logic.
Keep execution, memory, and repo state on infrastructure you control. Shared intelligence should live where your source of truth already lives.
Use the execution engines and runtime topology you actually trust. Clawteam is the orchestration layer above them, not a replacement for every substrate.
Task stages, runtime metadata, orchestration flows, and memory feedback stay visible in code, so the system can be audited and evolved deliberately.
Today: local-first orchestration and shared execution memory. Tomorrow: denser memory graphs, richer swarm coordination, and thicker reusable judgment.
FAQ
Clawteam is a local-first collective intelligence control plane. It is built to coordinate humans, coding agents, runtimes, and shared memory across the automatic product factory loop from idea to delivery.
Today the runtime detects and orchestrates Claude Code, Codex, OpenCode, Trae CLI, and Hermes Agent. The execution substrate can expand, but the operator surface and memory model stay unified.
Because isolated agent sessions do not compound. Clawteam is built around a shared memory spine so the product cell can retain execution outcomes, reusable skills, and future promoted knowledge.
Direct CLI usage gives execution. Clawteam adds the surrounding system: runtime boundaries, task graphs, fanout, memory feedback, delivery visibility, and one operator surface for the whole cell.
Memory and orchestration come first. The platform is moving toward richer shared memory, denser swarm coordination, and stronger reusable judgment — but always from a local-first execution core.
Execution happens in your local runtime or your own infrastructure. The browser is the entry point, but the intelligence kernel remains close to the repo, the runtime, and the memory boundary.