What is Disco Parrot?
An AI-native platform for planning, building, reviewing, and governing software with autonomous agents under human control. Reviewable autonomy as a product.
Most software teams that try an AI coding tool run into the same problem. The output is impressive, sometimes faster than a person could produce by hand. But no one is sure what changed, why it changed, or who agreed to it. A pull request lands on the screen and the team has to reverse-engineer the intent out of the diff.
Disco Parrot is built the other way around. It treats AI agents as workers your team can direct, watch, and pause, inside the same SDLC structure you already use. The work starts with intent, decomposes into reviewable pieces, runs in isolation, and lands as a normal pull request your team reads and merges. Every step is recorded.
Disco Parrot calls this operating model reviewable autonomy: agents move work forward on their own between checkpoints, and humans approve intent at the moments that matter.
The problem we are solving
The first wave of AI coding tools either replaced the keyboard (autocomplete, in-line chat) or replaced the developer (submit-and-wait batch generators). Both miss the part of software engineering that takes the most time: the work around the code. Writing a spec engineering will actually build. Breaking it into plans someone can review. Watching a long-running change without losing track of what it touched. Approving the parts that should be approved and rejecting the parts that should not. Leaving an audit trail a security team or a compliance auditor can actually use.
Disco Parrot does the work around the code, not just the code. The product is laid out as three areas, and once you know what each one is for the rest of the documentation makes more sense.
SDLC is where the work itself lives. Initiatives, plans, bugs, sprints, projects, portfolios, goals, the chat panel, the flow runs, the sessions index. Most users spend their day here. The URL for this area is /planning for historical reasons; the tab in the side rail is labeled SDLC, and the rest of the docs use that name.
Platform is where the agent is configured. AI models, agent instructions, skills, sandboxes, MCP tools, integrations, workflows. Most users land here once a quarter to find a setting an admin already configured for them.
Settings is where the workspace is administered. Members, teams, roles, secrets, plan and usage, the audit log.
The shape of a working day
A working day in Disco Parrot usually moves like this. A product manager writes an initiative on Monday morning and asks the agent to break it into plans. The agent reads the codebase in a sandbox, drafts plans with acceptance criteria, and the PM reviews them in the same grid as the rest of the team's work. An engineer picks up a plan, launches the Quick SDLC flow from the action launcher, and watches the agent plan, implement, and verify the change in the sandbox. The flow pauses at a checkpoint with the implementation in front of the engineer. They approve, the flow runs the create-PR step, and a normal pull request opens on GitHub authored as the engineer.
The team reviews the PR in GitHub the way they always have, and merges through GitHub the way they always have. The whole thing, the chat, the run, the steps the agent took, the files it touched, the decisions the human made, is recorded.
The next page walks through this run end to end.
What makes it different
Five things, all of which exist because reviewable autonomy is non-negotiable.
Approve, Reject, or Skip at the moments your team has chosen. The human is in the loop by default.
Every run lives in a disposable container with its own filesystem, network policy, and I/O sidecar.
Credentials are minted just-in-time, scoped to one command. A leaked transcript is not a credential leak.
Every record has a stable URL. The agent reads your work the same way you do.
Three records: tenant log, per-run transcript, per-record version history with non-destructive restore.
Human checkpoints, by default
A flow pauses for human approval at the moments your team has chosen. Approve, Reject, or Skip on every checkpoint. Background runs only auto-approve a checkpoint when the step is explicitly marked for it, and the auto-approval itself is recorded on the step. A human is in the loop by default, not by exception.
Sandboxed execution
Every agent run happens in a disposable container with its own filesystem, its own network policy, and a sidecar that mediates every I/O the agent makes. The agent cannot see your repositories, your credentials, or another tenant's data. The container is the boundary. Stop the run and the container is destroyed.
The agent never holds the keys
Credentials are minted just-in-time and scoped to one command. The agent receives an opaque handle or a delegated identity, not a token it can copy. A leaked agent transcript is not a credential leak. Five execution phases govern when a key can appear and through which delivery mode; managed keys are forbidden at every agent-facing phase.
An open work model your team and the agent both read
Every record has a stable URL. Every list is filterable, sortable, and shareable by link. The same records that you query from the URL bar are the records the agent reads at chat time, materialized as files into its sandbox, and writes back at the end of the turn. The system was built so the agent could query your work the same way you do.
Audit you can actually use
Three complementary records cover every change end to end. A tenant-level audit log of who did what. A Sessions index of every chat, flow run, and background task with its full transcript. And version history on every initiative, plan, skill, and agent instruction with a non-destructive restore. Every AI write is tagged at the source so an auditor can tell a human edit from an agent edit. The audit log exports as CSV from the UI for SIEM ingestion or compliance evidence, scoped to a permission your admin grants.
What runs the agent
The AI runtimes the platform supports are Claude, Codex, Google Gemini, and GitHub Copilot. You enable the ones you want, pick a tenant default, and let users or skills override on a case-by-case basis. Bring-your-own keys are first-class for Claude, Codex, and Gemini: the platform stores them in your tenant's Azure Key Vault, the agent receives delegated short-lived credentials at run time, and the keys themselves never appear in a transcript. GitHub Copilot uses your platform-managed Copilot subscription, since the Copilot runtime does not accept delegated keys today.
| Runtime | What it is |
|---|---|
| Claude | The primary runtime, run through the Claude Agent SDK. |
| Codex | OpenAI's Codex, for coding and agentic work. |
| Google Gemini | Google's Gemini models, run through the Gemini SDK. |
| GitHub Copilot | Models served through your Copilot subscription. |
Ask, when you do not want to change anything
Not every conversation with the agent ends in a pull request. A separate read-only conversation mode called Ask sits next to chat. Open Ask, point it at a project or a repository, and the agent reads your records and the codebase, answers questions with citations, and writes nothing back. A PM evaluating a feature, an engineer doing forensics on an old change, or a leader running a portfolio review opens an Ask without any risk that the agent will start editing the work. The same audit applies: the question, the answer, the records the agent read, all recorded.
Who it is for
Disco Parrot is the platform for teams who want to use AI to ship more software without giving up the structure that lets them ship it safely.
A product manager writes specs the engineering team will actually build, with the agent's help to fill in code-grounded detail.
A developer directs the work instead of typing it. Plans, implementations, verifications, and pull requests all start from one screen.
An architect encodes the conventions of the codebase in agent instructions and approved-tool sets so the agent's work fits the system the team has already built.
A QA engineer writes test cases against plans and verifies the agent's work the same way a person's work is verified.
An engineering leader gets throughput and a paper trail in the same product, instead of trading one for the other.
A security or compliance leader signs off on agent work because the structure (sandboxes, leases, checkpoints, audit) was built before the agent was, not bolted on after. The whole model sits on one page in the security overview.
Where you can run it
The Disco Parrot service is hosted on Azure. What you choose for your team is where the agent's sandbox container actually runs, since that is the boundary that matters when you bring data, code, and credentials into the picture. Three options ship today, and the choice is per workspace.
The fastest way to start. The platform operates the compute on Azure; your team brings the workloads.
An operator you install on your AKS, EKS, GKE, or on-prem cluster runs sandboxes inside your network boundary.
A developer-grade host running on Docker Desktop. Useful for offline development or strict-egress trials.
A team with strict data-residency or network-egress requirements lands on BYO Kubernetes. A team that wants to start trying it this afternoon lands on the managed pool. A developer working offline picks up Local Docker. The product behaves the same way across all three; the choice is about the compute boundary your security team wants to draw.