Built for query

If you treat your work as documents, the only tools you give an agent are search and summarization. It can fetch a page that maybe mentions the thing it cares about, and it can describe what is there. It cannot reason about the relationships, and it cannot write anything back that another tool will understand the next time it looks.

Disco Parrot treats your work as records. An initiative, a plan, a bug, a sprint, a goal, a test case: each is a structured object with a status, a fixed catalog of fields, and named relationships to the others. That choice makes a person's job easier, because lists become real queries and counts become honest numbers. It is also what lets an agent do its job at all. The same records that show up in your grid are what the agent reads when it goes looking for context to support whatever skill it is running, and what it writes into when the skill finishes.

From your browser

Every list in Disco Parrot is a query rendered as rows. You filter, you sort, you search, you paginate, and the query lives in the URL. The grammar is intentionally narrow: six operators (equal, not equal, in, contains, greater than or equal, less than or equal), a multi-key sort, a substring search across the fields that matter on each entity. That keeps a query something a person can read at a glance and something the system can validate without trying to be clever.

/planning/plans?filter=status:eq:in-progress&filter=owner:eq:alice&sort=updatedAt:desc

Share that URL with a teammate and they see your list. Pin it next to a project doc and the doc still resolves next quarter. Open it in two browsers and edits made in one show up in the other, because every meaningful change in the workspace (a status moving, a plan getting created, a sprint reordering) flows on a single event stream that every grid, board, and timeline picks up. The mechanics (filters and views in the grid, the board, the roadmap, and Quick View) each get their own task page. The thing to take from this page is that the URL is the saved view, the views all read from the same query, and the count on an initiative is the truth of its records, not last Friday's summary.

From the agent's runtime

The interesting part is the second consumer of the same records.

What lands at the start

When you open a chat against an initiative or start a Flow on one, the platform writes the focal initiative into the agent's sandbox as a markdown file with a YAML header. Its plans land alongside it, each in its own file. Test cases land under the plans. Documents attached to the initiative or any of its plans get materialized too. Tenant-wide bugs are written into a sibling directory so the agent can see the defect picture without having to ask. The sandbox starts with the work in scope, not with the entire database.

What the agent reads on its first turn is what the records actually say. A plan's status, body, steps, acceptance criteria, the initiative it belongs to, the sprint scheduling it. The agent can search the directory the same way you would: list the plans, grep for a topic, open the file. It is the same store that powers the views in your browser, materialized as files.

Reaching for more during the turn

The focal scope covers most of what an agent needs. When it does not (a related initiative this plan depends on, the sibling plans on a peer initiative, a similar piece of historical work to learn from), the agent reaches for more with a runtime tool the platform exposes for exactly this purpose.

The tool takes an anchor and a reason: load this related initiative, load the sibling plans for that one, search the tenant for plans whose titles look like this. The platform fetches the matching records and writes them into the same directory tree the agent already knows, next to the ones that were there from the start. The agent then reads them like any other file.

A ceiling sits on top of this for safety. The agent gets a handful of fetches per turn at most, and each fetch returns a small number of records. A runaway loop does not happen by accident, and a single turn cannot quietly pull half your workspace into context.

Edits flow back, with an AI mark

Records the agent fetched on demand are marked read-only. The agent can read them, reason against them, and quote them in its reply. It cannot silently rewrite them.

For the records that were in the original focal scope, edits go the other direction. When the turn ends, the post-turn sweep reads the changed files, parses the YAML and markdown, computes a hash, compares it to the baseline that was captured at the start, and upserts the change into the store. The version row is stamped with editSource: "ai". The audit log gets the event. The version history holds the body that landed. The SSE stream tells every connected client to refresh, and the list in your browser updates with the agent's work in it.

Why this matters

A queryable work model is not a feature; it is the substrate everything else in Disco Parrot is built on top of. The audit trail can answer "what changed" because the changes are typed. The rollups are honest because the underlying definitions are deliberate. The agent can write into your work and a person can sign off on it because both sides are pointing at the same record, with the same fields, in the same store. The agent's writes do not live in a parallel scratch space; they go back into the data your team is already querying.

Most platforms ask you to pick: a flexible document store that an agent cannot reason about, or a rigid issue tracker that everyone resents. The third option, the one we picked, is a model fixed where it matters (the fields, the relationships, the statuses) and configurable where it pays (which statuses, which labels, which fields show on a card). A model that a person can query through a URL and an agent can query through a runtime fetch, and where the writes from both consumers end up in the same place. That is what makes review by a person on top of an agent's work feasible. The agent's edits are not floating notes; they are rows in the same query you ran ten minutes ago.