The whole factory, as you will use it.
Every screen on this page is drawn from the Coroid portal. Work comes in from your team, your tools and automation, is built and verified by specialised agents, and reaches you as a pull request with its evidence.
Screens are recreated from the portal. Plan totals are from a real run; other example work is illustrative.
Work starts as a specification, not a prompt
Someone can describe it on the New Work form, import issues from a tracker or ask Coroid in chat. Your product and external agents can send work through the API and MCP, and your tools and automation can open it on their own. Every task carries the specification the agents build against.
- Goal, business value, user stories and acceptance criteria on every task
- Requests from people, your product and your tools are checked for duplicates, verified and stripped of secrets first
- A pull request, an issue in GitHub or Jira, a comment that mentions Coroid or a Slack message can start work
- Work also starts on a schedule, a platform event or a Sentinel watch, and findings from reports and quality checks can queue a fix
Finance teams keep asking for their invoices in a spreadsheet. Add an export button to the invoice list that downloads the current filter as CSV.
Done when: the file opens in Excel and Numbers, amounts use the account currency, and exports over 10,000 rows don’t time out.
Large work becomes a phased plan
When a request is too big for one task, the architect breaks it into ordered phases with explicit dependencies, checks that it is feasible and estimates what it will take.
- Phases and tasks run in dependency order
- Each task gets its own specification, agents and evidence
- A viability check scores feasibility and risk before work starts
- Tokens, cost, duration and emissions are tracked for the whole plan
- 01Project foundation scaffold1/1
- 02Shared runtime foundations3/3
- 03Era-aware city domains and UI8/8
- Era-evolving buildings and facades
- Storefronts and advertising per era
- Vehicle fleet and traffic by decade
- Pedestrian crowds in period clothing
- 04Composition and era morphing1/1
- 05Polish and acceptance verification1/1
- Final validation2/2
Create a 3D scene of a city block. Emphasis on detail is very important.
The scene must have a timeline slider at the top with the options 1945, 1965, 1985, 2005 and 2025.
Selecting a year transforms the block in front of your eyes: buildings, vehicles, storefronts, advertising and the pedestrians’ clothes.
- Tokens
- 83.5m / 112m
- Cost
- US$2.05
- Est. CO2e
- 1.59 kg
- Duration
- 6h 15m
One queue for everything that needs you
The Factory lists every plan and task by what it needs from you: a review, a decision on a problem, or nothing at all. Open any item to see its agents, criteria, evidence and full trail.
- Review what is ready and merge what you approve
- Problems arrive with the reason and the failed run attached
- Request changes and the work goes back through the line
- Every run is recorded, including the ones that failed
- Timelapse city block - Chrono CityTaskcity-sim1 day agoNeeds review
- Timelapse cityPlancity-timelapse2 days agoReady to merge
- Super Mario in 3DTask3d-game3 days agoNeeds review
- Conway’s Game of Life in 3DPlangame-of-life4 days agoReady to merge
- Street racing gamePlancity-timelapse5 days agoRunning
Capacity you can see and steer
Agent slots are your parallel capacity. Mission Control shows what fills them, what is next, when the queue clears and what is scheduled, and pauses everything with one switch.
- Work is picked up in priority order as slots free up
- A 24-hour horizon of queued and scheduled work
- A live run log of starts, verdicts and handoffs
- Add slots when you want more work in flight
Export invoices as CSVQA
Fuzzy search in the customer listDeveloper
Onboarding checklist for new teamsArchitect
- Reviewer approved “Dark mode for settings”
- QA verified 5 of 5 criteria on “Invoice PDF footer”
- QA sent “Search filters” back: criterion 3 unmet
- Architect started “Onboarding checklist”
- Retry failed webhook deliveriesP1
- Upgrade the date libraryP2
Quality gates you decide
Delivery assurance is built in: every task is verified against its criteria and reviewed. Quality Control lets you add the checks a project needs and holds every pull request to them.
- Organisation policies with per-project overrides
- Browser tests and evaluations run against the real build
- Coverage, security scans, previews and visual diffs attach as evidence
- Every gate run is recorded against the pull request it judged
- Delivery assuranceAll projectsv7 · Built-in checksActive
- Work qualificationAll projectsv16 · 6 checksActive
- Checkout release gateweb-appv3 · 4 checksActive
- Build and type check
- Acceptance criteria 5/5
- Browser test: checkout flow
- Dependency audit
- Coverage below target (advisory)
From merged to deployed, tracked
A release pins one commit and follows it through your environments, with the checks and approvals each one requires, until the deployment is confirmed.
- Staging and production, each with its own approvals
- Every build carries its version and build number, and Coroid confirms what runs
- Release trains group the work that ships together
- Recovery paths for when a deployment goes wrong
- Spring fixes2.5web-app · release/2.5.06 itemsStagingProductionDraft
- Checkout refresh2.4web-app · a1f3c9e5 itemsStagingProductionAwaiting approval
- Search improvements1.1web-app · 7be02d43 itemsStagingProductionDeploying
- Team onboarding1.0web-app · 249cee48 itemsStagingProductionShipped
A Coordinator steers the specialists. Gates decide when work is done.
Each task has a Coordinator. It plans the work, gives the developer, QA and reviewer agents clear instructions, answers their questions and decides what happens next from what they report. It cannot declare the work done on its own.
Every task ends in a pull request for your team to approve, in QA's confirmation that the code already does what was asked, or in a failed task that says why. Limits on rework, plan changes and run time keep a Coordinator from looping forever.
- 01
Plan
The Coordinator reads the repository and the specification and writes the plan, including the acceptance criteria that decide success.
- 02
Delegate
It hands the work to one specialist at a time, with clear instructions. The developer builds, QA verifies the result, and the reviewer reads the diff.
- 03
React
When QA fails the work or the reviewer asks for changes, the Coordinator sends the fixes back to the developer, and QA checks the new version.
- 04
Gate
The task can finish only when QA has passed the exact version that will ship and, where review applies, the reviewer has approved it. The Coordinator cannot overrule either verdict.
Qualified work enters the factory
Raw requests are evidence, not instructions. Coroid sanitises, deduplicates, and verifies each request before an agent can act on it.
Passing requests promote automatically. Contradictory, low-confidence and unverifiable cases stop in an audited review queue.
The workflow begins with untrusted signals from manual requests, imports, API calls, and integration events. Coroid normalises and sanitises the input, checks whether the current release or canary already fixes it, deduplicates and clusters matching reports, verifies the request with type-aware checks, and assesses impact, ownership, scope, difficulty, and confidence. Passing requests become a task, phased plan, report, or schedule. The implementation must then pass the same compiled Quality Graph at pull request, release, and canary checkpoints. Passing release evidence closes the original feedback.
- 01
Raw signals
Manual requests, imports, API calls, and integration events enter as untrusted input.
- 02
Normalise and sanitise
Credential-like values are redacted and every tool remains constrained to the selected project.
- 03
Check the current release
A request that is already fixed on the latest release or canary closes with evidence.
- 04
Deduplicate and cluster
Exact identity, content fingerprints, and semantic confirmation join repeat signals to one issue.
- 05
Verify the request
Type-aware checks establish whether the requested outcome is real and feasible before it becomes work.
- 06
Assess and route
Impact, owner, scope, difficulty, confidence, and the right work type are recorded.
Create the right work
- Executable task
- Phased plan
- Evidence report
- Recurring schedule
Prove the outcome
Close feedback. Release evidence updates the originating system when its integration allows writes.
An assistant writes the code. Coroid handles everything around it.
AI coding tools are good at the middle of the job: writing the change. Most engineering time goes to everything around it. Someone has to decide what is worth building, prove it works, keep it governed, and answer for it later. Coroid does those parts too, so the work keeps moving instead of queueing behind one person.
The question your team will ask
Agent sessions, local or cloud
Coroid
- Where does the work come from?
- Agent sessions, local or cloudSomeone stops what they are doing and writes a prompt, or assigns a ticket to an agent.
- CoroidQualified requests from people, your tools, and your pull requests. Automation you set up also opens work, within the limits you choose.
- Who decides it is finished?
- Agent sessions, local or cloudWhoever is reading the diff, with the judgement they have that afternoon.
- CoroidA compiled quality graph that returns one decision: go ahead, or redo.
- What proves it works?
- Agent sessions, local or cloudA transcript, and whatever tests the agent chose to run.
- CoroidChecks that actually executed, bound to the exact commit, attached to the pull request.
- What happens overnight?
- Agent sessions, local or cloudRuns already started finish, then wait for someone to check them. Nothing new starts until someone asks.
- CoroidThe line keeps running. Work stops only at the gate that genuinely needs a human.
- How do you add throughput?
- Agent sessions, local or cloudMore sessions, each needing someone to start, check and follow up on it.
- CoroidAnother agent slot. Members are unlimited; capacity is the thing you buy.
- Who governs which models see the code?
- Agent sessions, local or cloudEach tool’s own settings, managed one tool and one seat at a time.
- CoroidOne versioned policy ceiling above every project. Projects may tighten it; nothing widens it.
- What can you hand an auditor?
- Agent sessions, local or cloudSession logs, in each tool’s own format, for as long as that tool keeps them.
- CoroidAn append-only event stream, signed and exported to your SIEM, with a retention window you set.
Coroid is not trying to replace the editor your developers like. It replaces the unmanaged space around it.
Quality costs tokens. That is the point.
A factory task spends roughly two to three times the tokens of a single agent session in Claude Code, Codex or Gemini CLI, because separate agents plan, test and review the work before it reaches you. You are buying consistency, not keystrokes.
Token spend per equivalent task, relative to a single agent session.
Prefer raw speed over ceremony? The Ludicrous profile relaxes the gates and matches CLI-level token spend. It is there when you need it — it is just not why Coroid exists.
Explore AI profilesIt joins what you already run
There is no IDE extension to install and no agent to keep alive on a developer's machine. Coroid connects to the systems your work already passes through.
- Repositories
- GitHub, GitHub Enterprise, GitLab, and self-hosted Git. The GitHub App carries inbound checks and inline review; project-scoped tokens carry clone access.
- Signals and tickets
- Jira issues, Slack messages, and GitHub issues and comments can arrive as qualified requests. Automation you set up can act on Sentry and any MCP server you connect.
- Previews and evidence
- Vercel, Netlify, and Cloudflare Pages deployments, plus coverage, security scans, visual diffs, end-to-end runs, and third-party AI reviewers.
- Models
- Frontier and cost-efficient models routed per agent, with EU-only and low-carbon profiles. Bring your own provider keys or use Coroid credits.
- Security and observability
- Signed audit export over HTTPS to Splunk, Datadog, Chronicle, or any collector you point it at.
- Where it runs
- Coroid cloud, the EU hosting profile, or your own Docker Compose or Kubernetes deployment.
Every capability, in detail
What each part of the factory does, and how. Where a capability depends on a plan, it says so.
Work intake7 capabilitiesRequests from people, your product, and your tools are qualified before they become work. Your automation and external agents create work within the permissions and limits you choose.
- Specifications
- Every task carries its goal, business value, user stories, acceptance criteria, context, and constraints. Agents build against that specification, and the pull request that comes out stays linked to it.
- Work Qualification
- Requests are treated as untrusted input. Coroid redacts credential-like values, checks whether the current release already fixes it, deduplicates by fingerprint and semantic match, verifies the request with type-aware checks, then records impact, owner, scope, difficulty, and confidence before any work exists.
- Phased plans
- An initiative too large for one task is decomposed into ordered phases with explicit dependencies. The architect resolves ambiguity from the evidence it has and records its assumptions rather than stopping to ask.
- Event automations
- A pull request, an issue or PR comment, a Slack thread, or a connected Jira issue can start work. Each signal becomes qualified intake, an inbound check, or a hook run — never an open-ended agent session.
- Hooks and schedules
- Organisation automations fire on task, agent, repository, analysis, sync, and deploy events, or on a recurring schedule. They are read-only by default, rate-limited, and capped by chain depth so an automation cannot trigger itself into a loop.
- Sentinel
- A watcher on Sentry, Jira, GitHub, and Slack that turns what it finds into tasks on the same line, instead of into another alert nobody owns.
- Dependency graph
- Tasks and projects declare what they depend on, across repositories and across the organisation. Cycles are caught before execution and global runs are ordered so parallel agents do not collide.
Execution9 capabilitiesSpecialised agents, one isolated workspace per task, and no session anyone has to keep alive.
- The agent line
- Architect, developer, QA, and reviewer are separate agents with their own prompts, tools, and model assignments. Work moves between them when a gate opens, not when a human pastes context into the next window.
- Explorer subagents
- Any agent can fan out two to five focused explorers — patterns, dependencies, APIs, tests, configuration, security — each on a share of the parent's token budget, and fold their structured findings back into one context.
- Isolated cloud workspaces
- Each task is provisioned its own workspace with project-scoped repository access. Nothing requires an IDE extension, a terminal on someone's laptop, or a route into your private network.
- Model routing and AI profiles
- Choose the model per agent, or run a system profile: quickest, most capable, EU-only, or low carbon. Bring your own provider keys, or use Coroid credits at pass-through rates.
- Decision engine
- A dedicated decision model chooses from known options for acceptance evidence, QA preflight, work qualification, and task routing. Each answer is validated, confidence-checked, and recorded, and Coroid falls back to the existing evaluator when confidence is low.
- Progressive skills
- Agents read skill metadata first and load full instructions only when the work calls for them, so context goes to your codebase instead of to tool schemas. Projects can define their own skills.
- MCP tool access
- Connect Sentry, Jira, Slack, or any MCP server and agents call those tools under your organisation's tool policy — no bespoke integration code per service.
- Autonomous remediation
- A failed dependency install, a bad configuration, or a broken build is diagnosed and fixed inside the task when it is simple, and escalated into its own remediation task when it is structural.
- Scratch projects and previews
- Generate a codebase from a single prompt with no Git host attached, watch it run in a preview, iterate on it, and graduate it to GitHub or GitLab once it has earned a repository.
Quality and review8 capabilitiesOne compiled graph decides, and it decides the same way for a manual check, a task on the line, and a pull request your own developer opened.
- The Quality Graph
- Goals, expectations, and checks compile into a single graph pinned to an immutable revision. The same graph gates a manual test, a task's QA, and a GitHub pull request, and returns one decision: go ahead, or redo.
- Evidence bound to the commit
- Verdicts come only from checks that ran, and results are locked to the revision they ran against. Nobody can hand-write a pass, and a stale green cannot carry a later change through a gate.
- Coroid Check on your pull requests
- Install the GitHub App and Coroid posts check runs and inline review on your repository's pull requests — including the ones your developers opened by hand.
- Lanes and merge gates
- Tasks integrate into a lane, the lane runs the unified quality pipeline across end-to-end, unit, static, visual, accessibility, security, and eval evidence, and only then opens a pull request. The merge policy is yours: human approval, automatic merge, or a deliberate override.
- Review rules as files
- Review standards are versioned Markdown files. Coroid ships a system set; a project's own rules directory extends or overrides it, so your standards live in the repository and travel with it.
- External review evidence
- Preview deployments from Vercel, Netlify, or Cloudflare Pages, plus security scans, coverage, visual diffs, end-to-end runs, and third-party AI reviewers attach to the review as first-class evidence.
- Browser-level verification
- The web tester drives the running application for functional, UX, accessibility, and security behaviour, and returns screenshots and findings as evidence rather than as a claim.
- Evals
- Run real workflows through the production pipeline to compare models, A/B test prompts, catch regressions, and price the cost-quality trade-off before a change reaches your repositories.
Governance and control8 capabilitiesSet the ceiling once, above every project — then prove afterwards what ran beneath it.
- Org policy control planeProfessional
- A hierarchical, versioned policy document sets which models may run, whether secrets are scanned, which sandbox commands are permitted, and how much autonomy agents have. Projects can tighten it, nothing can widen it, and published versions are immutable. Command and autonomy ceilings are Enterprise.
- Service accounts and scoped keysProfessional
- Named non-human principals for automations, schedules, and machine callers, each with its own scoped API key. They are not seats and not shared human credentials, and what they do lands in the audit stream under their own name.
- Audit event stream and SIEM export
- A normalised, append-only record of who did what, when, on which organisation, project, and repository, with which model, and what was decided — exportable to your SIEM over HTTPS with signed payloads and a retention window you control.
- Retention, legal hold, and purge
- Set how long Coroid keeps factory work product, anywhere from 14 to 365 days. Place a legal hold, purge a category on demand, and keep a record of exactly what each run deleted.
- Settings portability
- Export an organisation's policies, quality graphs, hooks, schedules, review rules, retention settings, and project gates as one portable bundle, preview the difference, and apply it elsewhere. Secrets stay redacted to placeholders.
- SSO and directory syncEnterprise
- SAML single sign-on and SCIM provisioning for organisations that manage access centrally.
- Isolation and credentials
- Repository and service credentials are scoped to the project and stored through encrypted configuration paths. Agents work in isolated workspaces and are never handed a route into your network.
- EU hosting and on-premisesEnterprise
- Run on the EU hosting profile, or deploy the whole factory with Docker Compose or Kubernetes on infrastructure you govern — runtime, storage, repository access, credentials, and network policy included.
Visibility and economics6 capabilitiesThe queue, the trail, and the bill are all in the open — including the parts that cost you money.
- Mission Control
- Production status, prioritised work, exceptions, remaining capacity, and everything waiting on a human, in one place, updated as the line runs.
- Execution trails
- Every agent step, decision, tool call, and model response is recorded and inspectable, with the tokens, cost, and estimated emissions attached to the call that produced them.
- Carbon estimates
- Operational inference CO2e is estimated for each model call and snapshotted beside cost, with its source and confidence declared. A low-carbon profile prefers smaller models and lower-intensity hosts. It is an estimate, not a neutrality claim.
- Capacity-first pricing
- You buy parallel agent slots, not seats. Organisation members are unlimited, and model spend stays separate — prepaid credits or your own provider keys — so throughput and inference never blur into one number.
- Reports
- Codebase and delivery reports on demand or on a schedule, exportable, produced by the same explorer agents that read your code for tasks.
- Codebase viability
- Coroid tracks file size, complexity, and pattern health against what an agent can actually hold in context, and proposes the refactors that keep your repository workable — for agents, and for the people reading after them.