Orchestrate the work,
not just the agents.
Orgabot coordinates agents, people, tools, approvals, and gates across an organization. Autonomous where it should be. Deterministic where it has to be.
- Local or cloud
- Agent agnostic
- Least privilege by default
- Human + AI workflows
- Compliance ready
Your organization already has a way of working. Make it executable.
Every team has an order of operations: who picks the work up, who is allowed to touch production, what has to be true before a change ships. Most of it lives in habit, in a wiki, or in one person's head. Orgabot models it as a workflow with triggers, actors, stages, gates, permissions, and outcomes, so the process runs instead of being remembered.
Work starts on its own
An issue, a schedule, a failing build, a person asking. The trigger decides which workflow runs and what it is allowed to do.
Roles, not accounts
A role is a position with an authority level. A human or an agent fills it, and either can be swapped without rewriting the process.
Work moves in steps
Each stage names who acts, which tools are reachable, and what has to be true before the next stage begins.
Some things are not judgment calls
Tests, reviews, approvals, and policy checks are evaluated on evidence. A gate that cannot be evaluated holds the work.
Access is part of the stage
Tool and credential grants are attached to the stage that needs them, so authority does not accumulate as work moves along.
Every run ends somewhere explicit
Delivered, held, or refused, with the reason recorded. A run that did not satisfy its gates never reads like one that did.
Reasoning where it helps. Rules where they matter.
Autonomous where it should be. Deterministic where it has to be. The split is the product: agents get real latitude inside a stage, and none at all over the conditions for leaving it.
Interpretation, planning, adaptation
- Interpret what was actually asked for
- Plan the work and decompose it
- Adapt when the codebase disagrees with the plan
- Summarize findings for the humans downstream
- Reason about tradeoffs inside the stage it owns
Permissions, approvals, gates, evidence
- Which tools a role may reach, and when
- Which approvals must resolve before work moves
- Which tests must pass, judged on exit codes
- Which security policies apply to the change
- Which environments a release may be promoted into
- What lands on the audit trail, and who decided it
- Issue createdDeterministic gate
- Agent investigatesAgent
- Agent implementsAgent
- Tests passDeterministic gate
- Security reviewDeterministic gate
- Human approvalDeterministic gate
- DeployDeterministic gate
Use the agents you already trust.
Orgabot orchestrates agents; it is not one. Workers sit behind a single adapter contract, so the agent that runs a stage is a configuration decision, not an architectural one. Swap providers per role, per stage, or per project without touching the workflow.
- Claude
- Codex
- Gemini
- Custom agents
- Local models
- Whatever ships next
The same applies to where a model runs. A stage that must not leave your network can be served by a local model while the rest of the workflow uses a hosted one, because the gates around both stages are identical either way.
Designed around least privilege.
An agent should not inherit your access just because it is working on your behalf. In Orgabot, an agent starts with nothing and receives exactly the grants its stage requires, for as long as that stage lasts.
- Scoped credentials, granted per role rather than per organization
- Access that exists only for the stage that needs it
- Explicit tool grants: nothing is inherited by being nearby
- Secrets held by the infrastructure, never pasted into a prompt
- Every elevated action recorded with the authority it acted under
Your secrets are not prompts.
Credentials belong to the infrastructure that executes the call, not to the model that decides to make it. Orgabot holds secrets behind tools: an agent asks for an action, the broker performs it with the credential, and the secret never enters model context or a transcript.
From one founder to an entire organization.
The same primitives at both ends. A founder writes a four-stage workflow; an enterprise writes forty and shares them across teams. Nothing changes shape in between.
A company that ships like a team
- A coding agent that opens the pull request
- A test agent that has to pass before anything moves
- A deploy agent that cannot act without your approval
- A marketing agent with the socials and nothing else
- You, in the one seat that actually needs a human
Autonomy without losing control
- Engineering teams working from shared workflow templates
- Security review as a required stage, not a reminder
- Compliance gates that block rather than warn
- Release approvals routed to the role that owns them
- Several agent providers running side by side
- One audit history across all of it
Make compliance part of the workflow.
Controls that live outside the process get skipped under deadline. Controls that are stages cannot be. Orgabot produces the evidence auditors ask for as a byproduct of doing the work, because the gate that produced it is the same gate that let the work continue.
- Evidence trails: what ran, what it returned, what was decided
- Approval history with the identity behind each decision
- Separation of duties enforced in code, not by convention
- Policy that fails closed when it cannot be read
- Reproducible runs you can replay after the fact
What we do not claim
Orgabot is not SOC 2 certified, and no software makes you compliant. What it does is support the controls an audit asks about: separation of duties, approval records, access scoping, and an evidence trail you can produce on request. The certificate is still yours to earn.
Build the organization your agents can safely operate inside.
Orgabot is being built in the open and it staffs and ships itself, mission by mission. The Discord is where that happens.