Documentation

Build an agent team you can return to: give it roles, shared context and a place to work, then talk to it through Slack or a terminal. Steadmesh runs the team on Kubernetes, with its structure declared in Terraform.

New to Steadmesh? Watch the introduction for a short tour before choosing a setup guide.

Start with a team and a task

Start with a small piece of work and the roles it needs: perhaps a representative to talk with you, an engineer to make a change and a reviewer to check it. In an infrastructure repository, you describe the organisation's culture, teams, seats, harnesses, memory, tools, communication routes and external connections. Running terraform apply provisions it on Kubernetes. Once it is ready, each person can message their own representative, which keeps persistent context, delegates through the routes you declared and reports back. Work items can also be mirrored to a tracker such as Linear.

To run it you need a Kubernetes cluster whose CNI enforces NetworkPolicy, a default StorageClass, Terraform 1.5 or later and kubectl. For real work you also need credentials for the model providers your seats use, and a Slack app or terminal access for the people who talk to it. Model usage is billed by your provider.

Ways to put a team to work

• Take a repository change through review. Give an engineer and reviewer access to a test repository, ask for a small improvement, and follow the pull request from your representative. Start with the example organisation.
• Keep project context between conversations. Use personal memory for each representative and shared memory for team decisions, plans and working notes. Add work items when ownership and dependencies help.
• Return to work on a schedule. Ask a seat to set a reminder or a recurring check on a service it can access. Automations wake the seat with your instruction, using its existing tools and permissions.
• Try several approaches without changing your workspace. Use disposable workers for an explicit text task, or run alternatives to compare two to four approaches and record a reviewed choice. Their output shares the parent's model budgets; result files are not applied automatically.
• Give different roles different tools. Combine Claude Code, Codex and Pi seats, with a model and access profile suited to each role. See Harnesses and models and Sandbox access.

These are starting points for your own instructions and configuration. Begin with a bounded task, review what the team produces, and expand its access as needed.

Choose a route

How it fits together

Terraform is the desired-state interface. The controller keeps running after Terraform exits: it wakes sleeping seats when messages arrive, stops idle ones, recovers crashed ones and reports readiness. Seats act on external services by calling tools on the platform service, which checks each call against the grants you declared, and they reach models through the platform's model proxy, which holds the provider credentials.

Check the credential boundary before adding access. With GitHub sandbox delivery, a seat deliberately receives a GitHub credential it can read and use with git and gh, and browser sessions deliver stored session state into the sandbox. Secrets that Terraform creates can also be present in that stage's state. See where API keys go and GitHub and the sandbox.

Core concepts

Shape how your team works

Use instructions to describe how the team should divide work, share context, review changes and report back. Steadmesh provides the seats, memory, execution environments and capabilities; you choose the roles, approval expectations and definition of done. Agents coordinate within that setup. Projects and tasks live in the organisation's work items or your tracker, while Terraform defines the team and its access.

Common questions

• Prerequisites and layout: Is my kind cluster clean?
• Models: Where is the Pi key? · Which LLM does it use?
• Talking to it: How do I chat with my representative?
• Watching it: How do I see the organisation working? · What does “lease held” mean?
• Credentials: Where do API keys go? · How do agents use GitHub?
• Persistence: Does each agent keep its context? · Where is the data stored?
• Teardown: How do I take it down?

Release and test coverage