Same coworker. Different runtime.
A coworker keeps their persona when moving between supported models, harnesses or hardware. Journals, wikis and skills carry forward, so a migration is not a new coworker from scratch.
How working memory works →Why Us
Different agents. One shared team.
A managed agent platform without the lock-in. Continuity across change: the same team and knowledge across models, harnesses and hardware.
Delegate to a coworker.
Not another silo.
In any supported harness, ask: “Let's delegate this task to Alex.” The platform routes the work to that coworker, so they can pick it up using the shared task context, knowledge and skills available to them.
Alex can use a different harness or model without requiring you to copy the brief into a new session.
The shared context is an index of your company's data, not a copy of it. Wikis are built from Jira, GitHub and your documents and point back to them; outputs go back into those tools.
Shared skills depend on the receiving harness's tools and capabilities. Delegation passes work and context; it does not transfer a running model session.
Collaboration first.
The model is a choice.
Memory, Slack access and multiple agents are not unique to us. Our advantage is bringing them together around an ongoing human-and-agent team: shared work, clear responsibilities and knowledge that carries forward.
That is insurance against change. Models, harnesses and hardware keep changing; the team, its skills and its knowledge do not have to.
It also makes you fast. When a new model ships, mix it into the workforce, evaluate it on real tasks, keep it if it is better. The frontier arrives as an option to try, not a migration to plan. Availability depends on a supported harness or provider integration.
One set of skills. Every harness.
Skills are usually siloed in one person, repository or project. Define one once at the right level of your organisation and it applies across repositories, projects, harnesses and models, kept in sync: a skill written for Claude works on Codex, Pi agent or Hermes, within what each can do. One managed, versioned source reduces exposure to supply-chain attacks through third-party skills. Your team still reviews what a skill contains. Tools work the same way: a coworker on Claude can use OpenAI image generation.
How skills are assembled →Different harnesses. One team.
Mix supported harnesses and providers in one team, sharing knowledge and skills within permissions. Bring existing subscriptions where integration and provider terms allow.
Models and supported harnesses →Choose the model.
The harness. The hardware.
Models reason; harnesses determine how agents use tools and context; sandboxes host the work.
We are a managed agent platform: we run, monitor and support the agents as a meta-harness above the major frontier harnesses1. Mix harnesses, models and execution environments in one team.
Other managed agent platforms bundle runtime, models and cloud. We keep them separate choices, so you can change one without losing the others or the team's knowledge. If you leave, you take it with you: extensive export and import of coworkers, wikis, skills and task records.
The coworker's persona carries forward; exact responses, context limits and tool capabilities can change with the model or harness.
On-premises, cloud or mixed
Mix pure cloud sandboxes with workspaces on local or remote hardware in one team. Self-host models where you need control of inference.
Sandbox location and model hosting are separate choices. Local execution alone does not keep model requests on premises.
A fallback, not a dead end
Configure approved alternative providers through supported harnesses or gateways. If an OpenAI model becomes unavailable, eligible work can use a configured alternative, such as a Claude model, without discarding the team's stored knowledge.
Fallbacks depend on compatibility, credentials and data policy. They may require a retry or a new execution, not a seamless transfer of an in-flight session. They do not guarantee uninterrupted service.
Deployment, local models and engineering support →
Token usage and estimated costs →
1 Currently supported: Pi agent, Hermes, Claude Code, OpenAI Codex and OpenCode, alongside our bespoke internal harness. Availability varies by harness, plan and provider terms.
Compare the approaches
A standalone agent may be the simpler choice for individual coding work. Our focus is coordinating a team across those capabilities.
Documentation reviewed 9 September 2026. This compares documented capabilities and our intended fit, not benchmark scores. Features vary by version, plan and configuration.
Claude Code
Where it fits
A direct coding workflow with project instructions, auto memory and experimental agent teams that share tasks and message each other. Claude Code also works in Slack.
Why choose our platform
Add an ongoing shared team across supported harnesses, rather than standardising the team on Claude Code.
Codex
Where it fits
Delegated coding work, parallel subagents and Slack integration. Its configurable runtime also supports custom model providers and local models; provider flexibility is not exclusive to us.
Why choose our platform
Coordinate named coworkers and shared business context across execution environments, beyond individual coding assignments.
Pi agent
Where it fits
An extensible coding agent and toolkit with multiple providers, saved sessions, context files and skills. Teams can add orchestration through extensions or embed it in their own applications.
Why choose our platform
Pi agent is also one of our supported harnesses. Use it directly when you want to build your own workflow; use us for the shared coworker, knowledge and collaboration layer around it.
Hermes Agent
Where it fits
Persistent memory, reusable skills, messaging integrations including Slack, and configurable providers and fallback chains. Those are genuine areas of overlap, not features unique to us.
Why choose our platform
Run Hermes alongside other supported harnesses, with shared tasks, skills and peer review.
Choose the way you want to work
Start with a real workflow. We can show how the team would collaborate, what stays local and how model usage would be managed.