Building what comes next.

Over 1,000 signups have joined Descant’s beta list. Our promotion so far has been one public announcement post, with no paid acquisition. To everyone who signed up, shared the work, or followed along: thank you.

Since that June announcement, we have been hardening Descant for closed beta. The next generation is being developed through work on TriviaPot, OH HAI, and Descant itself. Our September 11 post explains the engineering framework; this update is about making that capability ready for the people who will use it.

Descant is for engineering teams accelerating delivery, maintainers short on bandwidth, solo developers shipping products, and founders building with AI. You can start with a GitHub repository and a single issue.

If you build by describing what you want to an AI agent, Descant is for you too. Production-grade software needs more than a working feature: tests and CI, security, observability, resilience, and scalability. Descant brings disciplined engineering to foundations you may not yet know to ask for.

Our CLI and MCP interfaces give agents access to the same underlying capabilities and permissions as the human interface. An agent can help prepare your repository and issues and work with Descant on your behalf. You retain authority over scope, priorities, approvals, and spending.

We have been refining the tools agents need alongside the boundaries that govern their use. Capability approvals define permitted operations; isolated execution, restricted egress, scoped credentials, and review provide separate layers of protection.

The verification sandbox network has no general internet route and permits access only to designated supporting services. A malicious or misinterpreted instruction in an issue or repository cannot create an outbound route that the environment does not provide.

We are designing infrastructure to fit workloads ranging from one issue to multiple multi-gigabyte repositories and backlogs of hundreds of thousands of issues. Execution capacity and concurrency can grow when thousands of independent tasks are ready, governed by dependencies, shared-code constraints, and your budget.

Closed beta is approaching. The work now is bringing these capabilities together into a dependable product that meets professional, production-grade standards. Think about the first outcome you would entrust to Descant: one issue to finish, a product to build, a backlog to resolve, or a codebase to transform. Join the waitlist to follow what comes next.

Descant’s North Star is fully autonomous software engineering: a system that can carry an engineering goal through implementation, review, integration, and maintenance, with people setting direction and retaining authority over its boundaries.

Sustained engineering across an entire codebase is a necessary capability on that path. Real software evolves over weeks, months, and years. Requirements change, technical debt accumulates, and each completed change alters the work still to come. The system has to preserve architectural intent while adapting to what it discovers.

Completing one difficult coding task demonstrates a useful capability. Carrying a codebase through thousands of coordinated changes requires continuity: the ability to decompose goals, relate work, implement and review, groom and learn, and repeatedly converge as the product changes. That lifecycle is the framework we are building into Descant.

Descant assesses whether an eligible issue is too large for a focused pull request. Oversized work is decomposed into smaller issues with explicit scope and relationships. A single product brief can grow into hundreds or thousands of issues as requirements are broken down and implementation reveals missing pieces. Small pull requests keep that effort incremental and reviewable.

Issuegraph frontmatter and labels make the plan machine-readable: where work was decomposed from, what belongs together, what must be serialized, and what is blocked by a dependency. These relationships let the system coordinate changes without losing their connection to the original goal.

Implementation and separate review operate within the current issue’s scope. Tangential fixes, technical debt, and out-of-scope improvements become follow-up issues. Leaving the codebase better includes preserving those discoveries so they can be prioritized and addressed.

The same discipline matters in an established enterprise system. A large technical-debt backlog needs careful sequencing and architectural continuity. Replacing a shared contract, migrating its callers, and retiring the old implementation are related changes whose order matters. Sustained engineering carries that sequence through while keeping each individual change focused.

Every completed change affects the surrounding backlog. Related issues may need updated context, narrower scope, a new dependency, repurposing, or closure because their work is already satisfied. Grooming reconciles those issues and records relationships at the edges as they become apparent.

Documented learnings carry architectural decisions, repository conventions, and resolved review findings forward. Incremental compression and relevance updates keep that knowledge useful as the codebase evolves. Analysis of pipeline runs also surfaces opportunities to improve quality, cost, and efficiency. Each run should leave the next one better informed.

The result is repeated convergence. Discovering necessary work can expand the backlog before implementation catches up. As related changes land and residual work is resolved, the system converges on a working product. New requirements begin another cycle, with the existing code and accumulated knowledge as its foundation.

We develop the next generation of Descant through this process on TriviaPot, OH HAI, and Descant itself. TriviaPot reached a working product through an in-place rebuild, then went through a deliberate design overhaul. OH HAI grew from a small set of product-level issues into an application, service, CLI, and agent integrations.

That is why sustained engineering matters to the larger goal. Fully autonomous software engineering requires a system that can keep bringing real work to completion as the codebase changes. Our focus on convergence is bringing that system closer to closed beta.

TriviaPot was already an existing system when we put the next generation of Descant to work on it. We chose to rebuild in place. Keeping the repository made the old implementation easy to consult: it preserved product history, earlier decisions, and useful references while substantial parts of the system changed around it.

That is a demanding setting for autonomous engineering. Every change has neighbors. A new implementation must fit the surrounding application, and the code that remains can reveal follow-up work as the product evolves. Over weeks, the effort extended through the game, the mobile experience, support, release work, and the operations around the product. On September 3, the public website was updated to point to TriviaPot's live App Store listing.

The first wave of work grew quickly as Descant decomposed the rebuild and captured discoveries as follow-up issues. Creation initially outpaced completion. Then the balance shifted: the backlog narrowed as the implementation converged. By the beginning of July, TriviaPot was working well, with the core feature set in place.

We then chose a new direction: a full visual overhaul and the removal of real-money features for the free-to-play release. That deliberate expansion of scope drove the next rise in issues in early July. Descant carried the redesign across the application, then worked through the visual refinements and follow-ups. The numbered chart annotations show that progression from an expanding plan to a working product and onward into the next development phase.

Focused pull requests helped keep a large transformation tractable. Each change could be reviewed in context. Related discoveries could be captured without turning the current patch into an open-ended rewrite. Over time, that discipline changed the whole codebase: new capabilities arrived, existing foundations improved, and the work around launch was completed alongside the application.

This is the kind of sustained development we are building Descant for. We remain responsible for product direction, architecture, and engineering standards. The R&D version supplies an increasingly capable way to execute that direction across many changes, then brings the lessons back into Descant. TriviaPot is available on the App Store if you want to see the resulting product.

You know the least about a substantial engineering effort at its beginning. A product goal can be clear while the exact path remains incomplete. Implementation reveals a missing requirement, an assumption in neighboring code, or a dependency that the initial breakdown did not capture. Good engineering uses that information to improve the plan.

For Descant, this makes follow-up work part of the product's core behavior. A discovery needs a durable place to live, enough context to be actionable, and a relationship to the work that uncovered it. The next engineer should be able to understand why it matters without reconstructing a conversation that has already ended.

There is a balance to strike. The current pull request needs to satisfy its scope and meet the repository's standards. A useful discovery outside that scope should become follow-up work with its own priority and review. That keeps a small change understandable while preserving the opportunity to improve the surrounding system.

Our August work strengthened that connection between review, follow-up issues, and the relationships among tasks. The intent is straightforward: finish the change in front of you, preserve what you learned, and make the next piece of work explicit. People retain control over which issues are eligible and what comes first.

Repeated over weeks, this produces a different development experience. A larger goal becomes focused changes. Those changes uncover additional work. Review improves the implementation, while the discoveries improve the backlog. Each merge leaves more useful context for the next one.

This is the pattern we have been developing through TriviaPot and OH HAI. The payoff is sustained progress across the software lifecycle: features, maintenance, integration edges, and the less visible work that makes a product complete. Descant is designed to carry that effort forward, merge by merge, within the scope a team authorizes.

A list of issues tells you what exists. Coordinating the work also requires knowing how those issues relate. One change may depend on another. Two tasks may need to happen in sequence. Several smaller issues may come from the same larger goal. As more work happens autonomously, those relationships need a form that software can read consistently.

We created Issuegraph to express that structure inside existing issue trackers. The first public specification took shape on August 14. It gives work relationships a small, explicit, vendor-agnostic format, so the reasoning about what can happen next does not depend on a particular model remembering an earlier conversation.

The useful part is the shared contract. A team can keep its issues, priorities, and discussions in the place it already uses, while tools read the relationships needed to coordinate execution. A larger goal can remain visible as its smaller pieces are filed and completed. Dependencies can be inspected rather than left implicit in a plan.

For Descant, that matters as engineering moves beyond one ticket at a time. Decomposed work needs to retain its ordering. A follow-up needs to connect to the change that revealed it. People need a practical way to see the structure and adjust it. The graph above illustrates that idea: several focused changes can advance a shared outcome while respecting the work that must come first.

Issuegraph is an open specification stewarded by Autonomy. We want the work graph to remain useful across model providers, agent runtimes, and supporting tools. Explicit relationships provide a foundation for coordination even as the systems doing the work change.

The specification and its website are public. If you are building autonomous engineering tools or trying to make a substantial backlog easier for software to understand, take a look. Clear work relationships are a small piece of the overall system, but they support an important goal: consistent progress across many related changes.

OH HAI began with a problem we were experiencing ourselves.

We routinely run large numbers of autonomous agent sessions across multiple machines and model providers. The agents can work for long periods without supervision. But when an agent needs a decision, that question can become a stopping point inside the session that asked it.

We could come back hours later expecting work to be complete and discover that an agent had spent most of that time waiting for a simple answer.

Checking individual sessions for updates and unanswered questions does not scale. We needed one place where a fleet of agents could reach a person with updates, decisions, and tasks, and where a response could find its way back to the work that needed it.

Rather than make that communication model an implementation detail of another application, we started by defining the interface.

That became MA2H: an open protocol for coordination between a person and a fleet of agents across vendors and sessions. The important part was not a particular inbox or runtime. It was establishing a small shared contract that different tools and agents could implement.

The sequence was intentional. Agent systems are changing quickly. Where a useful boundary can be expressed independently of a particular product or vendor, we would rather establish that boundary first and build products against it.

Descant carried that direction into the open specification, supporting implementations, command-line tooling, and reusable skills intended to make MA2H straightforward to add to an agent environment.

Only after that foundation existed did we build OH HAI on top of it.

OH HAI began differently from TriviaPot.

Before we started building the application, we had already worked through the coordination problem and established the first versions of the MA2H protocol. Once that foundation was clear, we turned to the next question: what product should exist around it?

Working with the R&D version of Descant, we used that protocol and the product direction around it to seed the initial body of work for OH HAI. Descant expanded that starting point into the issues required to build the system, then carried those issues through implementation and review.

That work grew into a web application, service, CLI, hosted MCP interface, session and delivery behavior, agent integrations, and the product surfaces needed to make the whole system coherent.

We set the direction, product requirements, and architectural intent. Descant turned that direction into an implementation plan and carried the resulting work forward. We did not manually write the application code or work through the repository in an editor.

The first time we launched the initial web application, it started without errors. We were immediately able to use it for the first working communication flow based on the MA2H protocol.

That was not the end of development, but it was an unusually clean transition from an operational problem, to an open protocol, to a functioning product built against that protocol.

OH HAI was designed to be agent-native as well as human-facing.

Agents with shell access can use the CLI and maintain a persistent connection. Environments without a shell can communicate through the hosted MCP interface. Other agents can participate through the protocol using the connection model available to their environment. The app and web inbox give the person one place to receive updates, answer questions, and act on tasks.

Those interfaces all meet at the same coordination layer.

A question originating in one environment needs to retain enough identity and context to be answered somewhere else. Sessions can come and go without making the person responsible for monitoring each terminal. Delivery, reachability, identity, and routing have to remain coherent across the system.

That made OH HAI a useful proving ground for Descant: not because any individual component was unusually large, but because a complete product had to emerge across several interfaces and shared contracts.

Centralizing agent communication solved the original problem, but it exposed the next bottleneck.

Once enough autonomous work is running, one person can still become overwhelmed simply by being responsible for every question, exception, and operational decision flowing through the inbox.

Because OH HAI is itself agent-native, the coordination layer can also be delegated.

In our own workflow, we sometimes assign an agent to supervise the inbox with explicit authority to triage messages, unblock work, resolve routine CI and merge-queue problems, and make decisions within defined boundaries. That agent effectively acts as a deputy across the larger fleet, escalating the decisions that genuinely require us.

The amount of authority is situational. When Descant is working through large bodies of follow-up work where we care strongly that the work is completed correctly but are less opinionated about each implementation choice, the supervising agent can handle much of the coordination.

When we are actively shaping fundamental behavior in Descant's own pipeline, we keep those decisions close and work the inbox ourselves.

The goal is not to remove the human from the loop. It is to make the loop adjustable: human judgment stays concentrated where it matters, while routine coordination can continue without requiring constant human attention.

TriviaPot and OH HAI exercise almost opposite ends of the problem.

TriviaPot began as a substantial existing system and required sustained transformation across thousands of related changes. OH HAI began with a coordination problem, an open protocol, and a relatively small amount of product direction. Descant then turned that foundation into a working application spanning multiple interfaces.

Both require more than producing isolated code changes.

They require preserving intent while the work expands, discovering what the original plan did not contain, coordinating related changes, and repeatedly bringing those pieces back together into a coherent product.

OH HAI now provides the coordination layer we originally needed for our own autonomous work. Agents can keep working, people can step away, and questions that genuinely require judgment have somewhere durable to go. When appropriate, even the work of supervising that coordination can itself be delegated.

The same process that created that system continues to improve Descant.

Substantial product development becomes easier to reason about when each change has a clear purpose. A focused pull request gives a reviewer a manageable question: does this implementation solve the intended problem, fit the system around it, and meet the engineering standards of the repository? The answer needs to account for more than whether the code was generated successfully.

Descant's workflow is built around that discipline. Planning establishes the intended change. Implementation works within that scope. Review examines the result, and feedback becomes work to resolve. Keeping that loop focused helps a sequence of changes preserve architectural intent as the codebase evolves.

Our July work expanded the review performed before a pull request opens, alongside the separate review that follows it. The goal is to bring more scrutiny into the engineering process: catch problems, address findings, and send a better change into the next stage. Different perspectives are valuable when they produce concrete improvements to the implementation.

Review also needs a sense of scope. A finding about the current change deserves an answer in that change. A separate improvement needs its own piece of work. Preserving that distinction keeps review useful and makes the backlog more informative, without allowing a focused task to expand indefinitely.

Production-grade software depends on choices that compound: clear interfaces, sensible boundaries, maintainable implementations, and an understanding of why the system is shaped the way it is. Those choices have to remain visible as more changes arrive. We are building Descant to carry them forward across the software development lifecycle.

For a team, this should mean substantial work can advance under explicit priorities and merge rules while remaining understandable. Small pull requests are one part of that experience. Their real value is the cumulative result: a product that progresses through changes people can inspect and a codebase that remains a good foundation for the work ahead.

Every completed change contains information that can help the next one. An architectural boundary may become clearer. A local convention may turn out to matter in an unexpected place. A review may explain why an apparently simpler approach would have caused trouble elsewhere. Those lessons are part of the value of doing the work.

A sustained autonomous engineering system needs to carry useful knowledge forward. Descant's July work strengthened the connection between merged changes and the learning process, bringing the actual change and its pull-request context into that work. The aim is practical: future engineering should benefit from what the repository has already taught us.

Useful learning is specific enough to guide action. It explains the boundary to preserve, the convention to follow, or the reason a decision was made. It should help an engineer approach the next task with better context and fewer repeated discoveries. The codebase and its history remain essential references as the system changes.

This also connects learning to review. A resolved finding can teach more than a correction to one line. It may clarify a pattern that applies across the repository. Carrying that reasoning forward gives the next change a better starting point, while keeping the standards rooted in the actual project.

This is central to the Descant we are building. An issue advances through planning, implementation, review, and merge; the result then improves the context for subsequent work. Across many changes, the product develops and the system becomes better informed about the codebase it is maintaining.

We use the next generation of Descant across our own projects to refine that approach under different demands. The lessons improve both the individual repositories and Descant itself. For teams, the ambition is a development system that becomes a more effective collaborator over sustained work, with human direction, architectural intent, and engineering standards carried forward from one change to the next.

On June 27, we shared the first public benchmark announcement for the autonomous software engineering system we were building. The post reported 86.46% on SWE-bench Pro. It also described the pace of our own development: approximately 13,800 GitHub contributions over 60 days, with a previous annual contribution high surpassed in three days.

The result gave us a concrete starting point for talking about Descant. We were building a system that could carry engineering work through a disciplined process and produce changes that stood up to evaluation. The public announcement made that work visible and opened the conversation about what autonomous software engineering could become.

Our main focus is production-grade software engineering over sustained work. A useful system needs to understand the task, make a focused change, respond to review, and preserve the decisions that should guide future changes. It also needs to operate under the authority and standards of the team responsible for the repository.

That is the direction we are taking with Descant: an autonomous engineering system that helps build and evolve whole codebases. The benchmark announcement was an early milestone in that effort. The following months would bring more work on learning, review, work relationships, and the product experience around the engineering loop.

This journal brings those milestones together. Some are about how Descant develops a change. Others are about the products we build with its next generation and the lessons that flow back into it. Together they trace the path from a first public result toward a closed beta for teams with meaningful engineering work to delegate.

The original announcement is linked below. It records the 86.46% figure shared on June 27; the current benchmark section on our homepage carries the later published result. As we continue building, we will use this space to show what is changing and what it enables for the people and teams using Descant.