Disco Parrot Docs

An AI-native platform for planning, building, reviewing, and governing software with autonomous agents under human control. Reviewable autonomy as a product.

A worked example from intent to a merged pull request. The same shape every run takes, narrated on a real change.

Every concept Disco Parrot uses on one page, one sentence each, each one a click to its full guide. The map of the documentation.

The operating model behind Disco Parrot. Agents do real engineering work, you approve it at defined points, and every step is recorded and reversible.

How Disco Parrot organizes work. Portfolios, projects, initiatives, plans, bugs, sprints, and goals, and how they connect.

A Flow is a reusable definition of multi-step agent work. The steps, the inputs, the checkpoints, and what happens on success or failure.

One live list of every piece of agent activity. Flow runs, background tasks, and chats, in one place you can monitor and resume.

Checkpoints pause a Flow before a step so a person can approve, reject, or skip the work before the run continues.

What "the agent" actually is, and how Agent Instructions steer how every agent behaves across your workspace.

The AI runtimes that power your agents. Run Claude, Codex, Google Gemini, or GitHub Copilot, set defaults, and bring your own keys.

Skills are reusable, named instructions for one kind of work. Status-scoped skills decide which ones appear, and when.

Every agent action happens inside a disposable container, isolated per task and bounded at the wall. What runs inside, how profiles configure it, and how the lifecycle holds.

What an agent is allowed to do, and what it is not. Tool allowlists, credentials it never holds, and environments that only accept proposals.

The status machine each kind of work moves through. One per work type, customizable per workspace, and the anchor for status-scoped skills.

First-class documentation for every repository, kept in step with the code by a health review the agent can propose surgical edits against.

Your records are structured data, addressable from the URL bar by your team and from the agent's runtime when it needs to gather the context for the job it has been given.

Every change recorded, with who or what, when, and the AI mark. The system of record that makes agent work defensible.

How Disco Parrot connects to the rest of your stack. Four concrete categories, named clearly, each with its own setup flow and credential model.

Every meaningful edit to an initiative, plan, skill, or set of agent instructions is captured as a full snapshot with its source. Restore is non-destructive.

The surface where you triage, edit, and share. Sort and filter live in the URL, cells edit in place, and bulk operations scale across every page that matches your query.

The same records as the grid, drawn as columns by status. Drag, multi-select, swimlane, configure what shows on a card. Sprint boards mix plans and bugs in the same lanes.

Initiatives on a time axis, with five zoom levels, dependency arrows that prevent cycles, sub-task rollups, and drag-to-reschedule. Plus the cross-project view for the portfolio picture.

Peek any record in a modal over your list without losing your place. The same detail page renders inside the modal or full screen, and command-click still opens a new tab.

Every active chat, Flow run, and background task on one panel you can resize, resume from, and send work back to.

The drawer that opens on any record and offers the right skills and Flows for what you want to do next. Status-scoped, pre-filled, and one click from the work you are reading.

How to move around Disco Parrot. Three areas, permission-aware navigation that hides what you cannot see, project switching that does not reload the page, and an activity hub a click away from anywhere.

A project is where a team's work lives. Initiatives, plans, and bugs roll up to one. The team's repository binds to one. The default sandbox profile for runs is set on one.

A portfolio is for the people who need to look across several projects at once. The rollup container above projects, with team-based access and a privacy switch.

An initiative is the captured intent. Everything else in the work model is what the team does to deliver it. Clarifications, Revise Spec, dependencies, rollups, and the spec body that decomposes into plans.

A plan is the unit of work an engineer can actually pick up. Seven types, one shape. Each plan sits under an initiative; an implementation plan links a pull request, a verification plan holds a snapshot of test cases.

A bug is what your team hit on the way to delivering the work. Nine statuses, eight typed relations, and an initiative parent that is always required. The agent can suggest triage and surface potential duplicates as you file.

A sprint is the time-box your team works in. Team-scoped, holding a mixed backlog of plans and bugs, with per-member capacity recorded against the window. A deliberately small contract that makes room for the team to run their own rhythm.

A goal is the outcome a team is trying to ship. Key results are how the team knows it. Disco Parrot ties key results to the initiatives that actually move them, so progress updates as the work lands.

A test case is the reusable scenario your team runs against the work. Verification plans link test cases as snapshots; results are recorded through one strict path so the audit trail is honest about what was checked, when, and by whom.

A document is a workspace-wide record that you attach where it is useful. Upload from your machine or pull from Google Drive and OneDrive. The agent reads attached documents from the sandbox at the start of every chat.

The operational guide to editing Disco Parrot's workflows. The shipped status machines, the knobs admins can turn, how the cascade carries an edit from the status record to the AI tools the agent reaches for, and the parts that are deliberately template-fixed.

The operational guide to working with version history on initiatives and plans. How to open the history tab, what a version row carries, the diff view, the edits list, the restore flow, and the practical playbook for reviewing what the agent has been doing in your work.

The unified treatment of every count, sum, percentage, and capacity number that Disco Parrot derives automatically from your records. Plans progress, open bugs, sprint capacity, and key result auto-progress are one analytical concept with three subsystems and a shared design.

Ask the engineer. The read-only investigator surface for getting cited answers about your codebase and the work that built it. Ask how a feature is implemented, what decisions drove it, and what plans are tied to it; pin the answers for later.

The planning chat surface where the agent reads, drafts, and edits your records, runs code in a sandbox, kicks off Flows, and stays coherent across long sessions. The conversational surface where the work actually happens.

The authoring surface for Flows. Lay out the steps, bind a skill to each one, declare the inputs, set the checkpoints, write the conditions, and decide what happens when a step fails. The place you shape agent work to match how your team actually works.

Start a Flow run, choose how closely you watch it, read the step timeline and transcript, and approve, reject, or skip at each checkpoint. Plus retry, resume, cancel, and what the blocked and interrupted states mean.

The searchable index of agent work. Find a Flow run or a chat across the whole workspace, filter by who ran it, read its status and cost at a glance, and click through to the run timeline or the transcript. The page you go to when you need to find a piece of work, not the one in front of you.

Longer-running agent work that proceeds without you watching it. How a task is created, the states it moves through, how it waits for you in review before its work lands, how an agent fans out into a batch of sub-agents, and how you resume, cancel, or dismiss one.

Write a skill once and reuse it everywhere. Author a named prompt for one kind of work, pin the model it runs on, share it with your workspace, and decide which skills appear at which status. The how-to for building and curating the actions your team launches on a record and chains inside a Flow.

Write your conventions once and every agent follows them. Set the workspace-wide guidance every run reads, override it for a particular sandbox profile, draft it with the agent's help, and keep a full, restorable history of every change. The how-to for the single control over how agents behave across your workspace.

Give your agents the tools your team already uses. Browse a curated catalog, connect a server in a few clicks, sign in once, choose exactly which tools are on, and test the connection before any run relies on it. The how-to for extending what an agent can reach, with the reach enumerated and the credentials held server-side.

Choose the AI runtimes your agents run on. Connect Claude, Codex, Google Gemini, or GitHub Copilot with your own keys or on bundled spend, turn on the models you trust, set a workspace and a personal default, and test each one before you rely on it. The how-to for the runtimes behind every run.

How an agent's work becomes a pull request your team owns. Open a PR under your own GitHub identity, review the change in the app and on GitHub, and merge it where you already merge everything else. The how-to for the last step of agent work, the one that lands in your codebase.

Point Disco Parrot at the code an agent will work against. Add a repository under a provider, set the branch and clone depth the sandbox uses, confirm the credential can reach it, and put a documentation health review on a schedule. The how-to for getting your code into reach of an agent.

The credential side of connecting code. How Disco Parrot authenticates to GitHub and GitHub Enterprise, the three ways to hold that credential, how access resolves per person, and what changes when your repositories live behind a managed-user enterprise.

What happens to a pull request after an agent opens it. Your reviewers comment on GitHub, the agent reviews its own diff, and both streams become findings you resolve with a Fix this that writes new commits and rechecks itself until the work converges or asks for a person.

Every repository gets its own set of docs that lives in the platform, reads like a notebook, and the agent reads the same way it reads your code. How to fill the pages without writing them, edit and organize them by hand, and where they live and why.

How a scheduled review keeps a repository's documentation in step with the code. The agent reads what has changed and proposes edits as small, reviewable changes, each with the evidence behind it, that a person approves one at a time or a batch at a time.

A running sandbox is a real workspace, and sometimes you want to look at it from your own editor. How to open one in the browser to read or write, or in VS Code and JetBrains over SSH, with a time-limited session you can revoke at any moment.

Keep Disco Parrot initiatives, plans, and test cases in step with Azure DevOps work items. Connect with your own access token, map how your concepts line up with ADO work-item types, and work the same record from either side.

Make chat code-aware. Bind a GitHub repository, its issues and pull requests, and the GitHub Copilot runtime into one connection so the agent reasons against your real repository instead of talking about code in the abstract. This is code-awareness for chat, not work-item sync.

Bring files from Google Drive and OneDrive into the workspace document library with your own read-only connection, so the agent reads them as context. How the connection works, what comes across on import, and where the files land.

A plain answer to what Disco Parrot connects to right now, named by category, from work-item integrations and repository providers to document providers, notification channels, AI runtimes, and sign-in. Plus what reaches the agent as a tool rather than an integration.

The operational view of every sandbox running in your workspace. See what is live, what it belongs to, and how recently it ran; pause or destroy one; open it in your IDE; and clear out the inactive ones in a single move.

A sandbox profile is the reusable recipe a sandbox launches from, bundling the image, the repos, the runtime, the tools, the resources, and the policy. Configure one once and every sandbox of that kind comes up the same way, in a click.

Before an agent runs real work on a profile, boot a throwaway sandbox from it and probe what matters. Test profile reports whether the image builds, the repos clone, the tools answer, the runtime authenticates, and the credentials resolve, so you find a broken profile in a click instead of mid-run.

An environment is the named target a run works against, staging, production, a preview, and it carries the change policy that decides what an agent may apply and what it may only propose. Set the lines once per environment, bind it to a profile, and the riskiest changes route back to a person instead of going live on their own.

Decide where your sandboxes actually run. Let Disco Parrot run them on managed compute with no setup, or bring your own host, a Kubernetes cluster or a Docker engine you control, and keep every agent run inside your own boundary while the platform still supplies the image, the runtime, and the policy.

Run agent sandboxes as pods in a Kubernetes cluster you own. Install a small operator, and every sandbox launches inside your boundary, under your network policy and your audit, while the platform still supplies the image, the runtime, and the policy. The platform never touches your cluster API; the operator reaches out.

Run sandboxes on a Docker engine you control. Register a Local Docker host, run the operator on Docker Desktop, make it your default, and turn on persistent workspaces so an agent picks up where the last run left off instead of starting clean every time.

How a bring-your-own host connects to Disco Parrot without opening a single inbound port. The operator dials out over a managed channel, only small control messages and agent events cross it, your code and secrets never do, the tokens expire in minutes, and work already running on your compute survives a dropped connection.

A workspace is the boundary every piece of Disco Parrot lives inside. Create one, switch between the workspaces you belong to, rename and brand it, decide who owns it, let people in automatically by their email domain, and delete one when it has served its purpose.

How people sign in to Disco Parrot, how one account can carry several linked logins, how two accounts merge into one, how to see and revoke your active sessions, and how a verified email domain places people into a workspace on first sign-in.

How people get into a workspace and how you manage them once they are in. Invite by a shareable link, see who belongs, assign and change roles, count seats against your plan, and remove someone or leave, with the owner protected at every turn.

A team is a named group of people inside a workspace, and the way you grant a group access to the work it should see. Create one, add members at the right level, link it to portfolios and projects to open them up, set its working days and capacity, and hand it on cleanly.

How Disco Parrot decides who can do what. The scopes that name every action, the built-in roles that bundle them, the custom roles you build with a scope picker, and the danger levels and guardrails that keep a powerful action from being granted by accident.

How Disco Parrot holds the API keys and tokens your work needs without ever handing them to the agent. The per-workspace vault, tenant values with personal overrides, the rule that you set a value but never read it back, and the managed and custom keys you manage.

How Disco Parrot tells you what happened while you were working. The bell and the inbox, who gets notified for the work they watch or own, the categories you tune, the in-app, email, and Teams channels, the three layers of preference with the workspace kill-switch, and the rule that your own actions and the agent's stay quiet.

The recent-changes view of your workspace. What the activity feed shows, how it reads the same record as the admin Audit Log through a friendlier lens, who can see it, and how it differs from the notifications that come to you.

How a Disco Parrot workspace runs on a plan. The plan ladder from Free to Enterprise, the Plan and Usage page where you see your tier, capabilities, and consumption, the 14-day pilot, the way to request more capacity, and the default tier that runs without a license at all.

How Disco Parrot meters use and enforces the limits a plan sets. The way a quota reads, the caps on projects, flows, and members, what happens when you reach one, how sandbox compute hours are measured per seat or pooled across a team, and where you watch it all on the Plan and Usage page.

The whole of Disco Parrot's security model on one page. The container that bounds every agent, the credentials an agent never holds, the human approvals that gate what matters, least privilege built into every route, the trail that records it all, and the option to run the work in your own network.

The container that bounds every agent run in Disco Parrot. A disposable container per run, a gateway every action crosses, a working directory the agent cannot escape, hardening that drops privilege, and the reason the boundary is the container rather than the agent's good behavior.

How Disco Parrot lets an agent use your keys without ever handing them over. The per-workspace vault, the rule that a managed key never reaches the agent as an environment variable, the phases of a run and the narrow channels a credential can travel, and the boundary that refuses a forbidden key before a sandbox even starts.

How a credential reaches an agent run in Disco Parrot, for one operation and no longer. The just-in-time lease, scoped to a capability and a destination, granted or denied on the record, delivered host-side at the moment of use, and gone when the operation ends.

How an agent on your infrastructure proves who it is to your cloud without a standing secret. A workload identity you grant and revoke, a short-lived token projected at the moment of use, the federated trust that lives in your own cloud, and the same guarantee whether the agent runs in your Kubernetes cluster or on a Docker engine you control.

The governance view of keeping a person in the loop. Approvals are control points a run cannot pass without a decision, every decision is on the record with who made it and when, a background run advances only through the approvals you marked in advance, and the riskiest changes come back as proposals rather than being applied.

Least privilege has two halves, and Disco Parrot enforces both. An agent's reach is an enumerated set of tools, leased credentials, and the changes an environment lets it apply. A person's reach is a set of named scopes their roles grant. Both are bounded by design, both are auditable, and neither has a hidden way around it.

The record you hand a reviewer. Every change and every boundary event is written down with who did it and whether it was a person or an agent, the agent's edits are marked apart from your team's, the log exports to a scoped CSV, and the platform's security events carry their own evidence pipeline you can stream to your own Log Analytics.

The governance view of running agent compute inside your own boundary. Pods in your cluster or containers on your engine, under your own controls; an operator that only ever dials out, so nothing reaches in; code and secrets that stay on your side; a short outbound list you can allowlist; and your own compute, which the platform does not meter.

A plain-language map of what an agent can touch in your data and what it never can. It works on the specific work it was given through permission-checked tools, never your databases directly; your secret values, another tenant's data, and another run's data are all out of its reach by construction.

Where your data lives and how it is protected. Encrypted at rest in managed cloud stores, your secrets in a per-workspace vault, every connection in transit over TLS, the platform reaching its data through managed identity rather than keys, and your records scoped to your own workspace partition.

How the platform's controls map to the control families a security review checks. The architecture is built to be reviewable, the agent is treated as untrusted code rather than a trusted insider, and every control on this page is a mechanism you can inspect rather than a claim you have to take on faith.

How Disco Parrot is built, in one picture. One Node service and one React app, deployed as a single unit, with the sandbox host, AI runtime, connected tools, and git provider all swappable at the edges. A modular monolith by design, not a mesh of services.

Where your work is stored and how one workspace's data stays one workspace's data. Cosmos DB partitioned by workspace, history in a shared versions container, large fields that spill to blob storage, sessions in Azure Table, and schema changes that run as idempotent, hash-checked migrations.

How the browser and the agent stay in sync without a refresh. One server-sent-events stream carries change signals to the app, a separate streaming path carries an agent's turn token by token and survives a dropped connection, and a different channel entirely talks to the sandbox operators.

What an agent can actually do when it runs. A fixed set of tools in four kinds, every change to your work model checked for permission, rate, concurrency, version, and audit, and a surface that is decided before the turn starts and cannot be widened from inside it.

What happens to your Git history when an agent ships code. An ordinary pull request under the human's own GitHub identity, on a branch cut cleanly from your base, with GitHub holding the merge and the platform tracking the change by commit. The platform never writes back to your pull request.

Where Disco Parrot runs and what happens to your work when it deploys. One deployable unit on Azure Container Apps, agent sandboxes that run on managed compute or your own Kubernetes or Docker, and a rollout that does not drop the work in flight.

The lookup layer of the documentation. Exact field names, every status, the full permission scope catalog, plan tiers, quotas, and limits, each grounded in the live product. Where you confirm a value rather than learn a concept.

Every term Disco Parrot uses, defined in a sentence or two, A to Z, each one a link to its full guide. The fastest way to settle what a word means.

Every record Disco Parrot keeps, the fields on each one, the seven plan types, and the bug values for severity, priority, and resolution. The field-by-field reference behind the work model.

Every status a record, a flow run, a step, a task, a sandbox, or an environment can hold, the transitions between work-model statuses, and how the platform enforces them. The full status reference.

Every permission scope Disco Parrot ships, grouped by area, with its danger level and what it lets a holder do. The complete reference behind roles and custom permissions.

The eleven roles Disco Parrot ships, who each is for, and the scopes each one carries. The role reference behind every permission decision.

The five commercial plans, the capabilities each one turns on, and the quotas the platform enforces. The licensing reference behind what your workspace can do and how much.

The exact values behind the platform's connected tools and execution surface. MCP transports and auth modes, sandbox host kinds and resource classes, and the secret policy matrix.

The exact values behind the automation engine. Flow and step grammar, the expression syntax, per-skill output contracts, the real-time event names, and the platform's hard limits in one place.

How to read a failure and where to look before you fix it. The surfaces that tell you what happened, the shape of recovery, and a map to the scenario by scenario guides.

Fixing a flow run that stopped. A run that failed, a checkpoint waiting on you, a run blocked on something outside it, a run interrupted by an update, and the daily run and compute limits.

Fixing the compute under a run. A sandbox that will not start or is unhealthy, an environment that is degraded or blocked, a host you brought showing as disconnected, and a profile test run that failed.

Fixing a connection a run depends on. GitHub or Azure DevOps authorization, a repository that could not be cloned, a connected tool that will not connect or whose sign-in expired, and a document import that needs reconnecting.

Fixing access that was refused. A permission-denied message and the scope behind it, and the cases where an agent cannot reach a secret or a file it needs to do the work.

Fixing a pull request that would not open or a merge that would not go through. Why a PR fails to create, why one shows a bot as its author, the two ways work reaches your main branch, and why a merged PR is not the same as a finished plan.