Documentation

What is Coroid

Coroid is an AI software factory for production systems. Engineering sets the standard once, anyone in the company can ask for a change, and every change is built, tested and reviewed to it — with nothing to install.

Coroid is a hosted AI software factory for codebases you already run. It does software work end to end, and it does it the same way every time.

An agent session, on your laptop or in the cloud, needs an engineer to steer it: someone who picks the task, writes the prompt, tests what comes back, writes the follow-ups and decides it is done. The result depends on who that was and how carefully they worked that day. Coroid keeps that steering in the system instead. Engineering sets how work gets done once — the project context, the quality policies every change must pass, the review rules, who may start work and who approves it — and every request follows it, whoever asked for it and whether or not anyone is watching.

There is nothing to install and nothing to run. Coroid clones your repository into its own sandboxed workspace in the cloud, works there, and pushes a branch.

What makes it a factory

  • Anyone can ask. A support agent, a salesperson or an intern files work by describing an outcome, in the portal, in Slack or in your issue tracker. They need no CLI, and no knowledge of the code or of how your team delivers it.
  • One standard for every change. A one-line fix and a phased plan go through the same specification, QA, review and quality policies. What reaches you has already passed them.
  • Nobody has to steer. Requests, imported issues and automations feed one queue. Work starts when an agent slot is free, and when QA finds a problem, the work goes back to the developer agent on its own.
  • Every change explains itself. Who asked, who owns it, what was decided and why, what was tested and who approved stay with the change as its provenance.

What anyone gives it

A description of the outcome they want, in plain language. "Add rate limiting to the public API, 100 requests per minute per key, return 429 with a Retry-After header" is a good task. Nobody writes the implementation plan — that is the first thing Coroid does, and you get to approve it.

What engineering sets up once

Access to the repository, and any context that is not obvious from the code: architecture notes, conventions, a style guide. Then the quality policies and review rules that every change in the project must pass. Every task gets QA and a review by default, so the first task does not have to wait for any of this.

What you get back

A pull request, on its own branch, containing:

  • the code change
  • the tests that were written or updated
  • the result of running your existing test suite
  • a code review pass, with findings either fixed or listed

It stays linked to its specification, its plan and every agent run, failures included, so the next person to touch the code can see why it changed.

You review and merge it the way you would review a colleague's work. Coroid never merges on its own. You merge in your provider, or press Approve & merge in Coroid to have it merge the pull request for you.

Anyone asks

Add rate limiting to the public API: 100 requests per minute per key. Return 429 with a Retry-After header.

Set up once

A connected repositoryProject contextQuality policies
Plans, builds, tests and reviews in its own workspace

You get back

A pull request on its own branch

  • The code change
  • Tests written or updated
  • Your existing suite's result
  • A review pass, findings fixed or listed

You review and merge

Engineering connects the repository and sets the project context and quality policies once. After that, anyone can describe an outcome, and Coroid returns a pull request held to those policies, with the change, its tests, your suite's result and a review. Merging stays with you.

You do not need to be an engineer to use it

This is the part that changes how teams work, and it is easy to miss.

Submitting work to Coroid means describing an outcome. It does not mean reading code, running a CLI, understanding how the code works, or knowing how your team delivers software. An intern, a salesperson or a support agent who keeps hearing the same complaint can all file work directly.

That works because the process is not theirs to run. The standard engineering set — the checks, the review, the approval rules — applies to their request exactly as it applies to a developer's. Every request, whoever it came from, arrives as a tested, reviewed change that a developer approves or rejects before anything ships.

What that does to the backlog

Prioritisation exists mostly because engineering time is scarce. A request that would take an afternoon has to be weighed against everything else an engineer could do with that afternoon, so small, obviously-useful work sits unbuilt for months.

When the cost of attempting a request drops to an agent slot and some tokens, that calculation changes. Work that would never have survived prioritisation can simply be attempted, and judged on the result rather than on a guess about its value.

Be clear-eyed about what still bounds you: review capacity and agent slots. Coroid removes the constraint on who can ask and how much gets built in parallel. It does not remove the need for someone to read the result. Teams that adopt it well tend to find review, not building, becomes the thing to organise around.

Coroid runs its own agents

Coroid is not a wrapper around Claude Code, Codex, OpenCode, Pi, or any other coding harness. It runs a purpose-built agent runtime designed for unattended cloud execution.

For you, that means:

  • Nothing to install. No CLI, no editor plugin, no machine or server to provision. Coroid is entirely API-based and runs in the cloud.
  • No tool subscriptions. You do not need seats for a third-party coding assistant. Model access runs through Coroid, or through your own provider keys if you would rather contract directly.
  • Your laptop is irrelevant. Work continues whether or not anyone is logged in — which is what makes schedules, monitors and event-driven automation possible at all.

See The Coroid harness for what the runtime actually does differently.

Is Coroid the right tool?

Coroid is built for changing a codebase you already run, under review, to a standard you set once. That is a different job from prototyping — if you are validating an idea rather than shipping it, a prototyping tool will serve you better, and the two compose well. It is also a different job from an agent session, where an engineer hands one task to an agent and steers the result.

See Where Coroid fits.

What it does not do

Being precise about the boundaries matters more than the feature list:

  • It does not commit to your default branch on its own. Everything arrives as a PR.
  • It does not merge on its own. Approval is yours. When you approve with Approve & merge in Coroid, Coroid merges the pull request for you; see Merging.
  • It is not an editor plugin. Coroid is not a coding assistant that completes lines as you type. It operates on whole units of work while you do something else.
  • It does not work without a connected repository. See Connect your code.

How work is sized

Coroid works in tasks. A task is one unit of work that ends in one pull request. Larger efforts are expressed as a plan — an ordered set of tasks with phases — which you approve before anything is built.

The unit of parallelism is an agent slot. One slot runs one task at a time. How many slots you have determines how much Coroid can do at once, not how fast any single task completes.

Next

Create your account and organization — set up the workspace your work will live in.

Your coding assistant can do most of the setup for you. See Set up with your AI assistant.