The ticket is the definition of work

In my last post I laid out the argument for focused, open products built from the outset to work with AI agents via a clear API and hosted MCP server. The example application in that case was MemNote, a note-taking app that automatically gathers contextual information to aid in recall. The second application I built asks: what should a Kanban board become when agent-driven delivery outruns our ability to define and plan the work? I wanted a board that carries its own context, so defining work stops being the bottleneck. To understand why it was needed, it’s worth reflecting on how software development has changed over the last 10 months.

Getting up to speed

At Great Expectations we were early adopters of using agents to write code and through early 2025 we had pockets of success: a significant minority, but not the majority, of our work benefited from agents operating at the task level. The most effective developers at this time were the ones that did the detailed technical breakdown of the work themselves, assigned agents to those tasks, and reviewed the work. Over time the team shifted from primarily writing code to primarily reading code, but the productivity improvements were somewhat offset by the need for more detailed planning. However, as agents continued to improve, we were able to assign them more of the software development lifecycle (SDLC). By late 2025 we were able to use agents to do the initial task breakdown from the technical design doc (TDD), then from early 2026 we were using agents to draft the TDD.

By February 2026 all parts of the technical delivery were agent augmented, with agents writing the first draft of the technical design, task breakdown, and code changes. Using agents throughout our delivery dramatically accelerated our team: we were shipping much faster, and with agents we were able to go back and do the refactoring and test improvements that we never had time for previously. The product was more capable and of higher quality than ever before, but our tools weren’t keeping up. We had long used Jira for tracking work; a timeline view for the product lifecycle and a Kanban board for the software lifecycle. But with the new way of working Jira changed from being a valuable tool to understand status, identify blockers, and spot delivery opportunities, to being more of a speedometer and an agent work queue. What in early 2025 still looked like developers working on individual tickets became flocks of tickets moving across the board — the individual tickets didn’t convey their prior understanding, and furthermore, we didn’t need them to. Our timeline view for epics, which used to burn down at a gentle 30-degree slope month over month, was now falling closer to vertical — we no longer needed to agonize over schedule and dependencies the way we had when software development was the overarching constraint. And while these views were fun to look at, for our product development team of 16, Jira had lost most of its value.

Figure 1: Old vs new timeline chart

With the definition of work spread across Confluence, Jira epics & tasks, and Figma it was onerous to gather all the context and pass it to an agent. While we managed the APIs and integrations for each product in a shared repository of connectors and skills, updates in one place were still lost in translation to the other and it was hard to ensure changes in upstream docs had the appropriate impact on downstream artifacts. The epic owner was taking on much of the coordination work across all of our artifacts and was overwhelmed and underinformed. Back when developers were primarily authoring the technical design, task breakdown, and the code, development moved slowly enough that ad hoc updates from product and design during development were picked up and incorporated. Now with developers delivering work much more quickly, having the definition of work spread across multiple tools was a huge drawback, and traditional integrations (consisting mostly of links to docs across products) weren’t as effective with agents as the consumer.

The majority of Jira features, the workflows, integrations, and custom metadata, while well suited to optimizing an onerous, multi-party delivery process, were unnecessary when 1-2 developers were delivering entire epics in days. Worse, the proclivities of each tool in our suite (Confluence for PRDs and TDDs, Figma or scratch repos for designs, and tickets in Jira) drove a diffusion of context: Confluence held the why, Figma the what, Jira the who and when, but no tool held the full picture. Our retrospectives surfaced this as a communication problem, and we responded accordingly: tighter updates on changes, clearer gates and consensus mechanisms. That helped at the margins, but communication wasn’t the real problem. We had heavy-weight tools trying to satisfy what had become, over a matter of months, a much lighter-weight effort. What we actually needed was for the full definition of work to land in the Jira issue description — for Jira to do far less in most respects, and to be great at the one thing it was never built to do: capturing and maintaining, as a single document, the context required to deliver the work. Other tools in the category (Linear among them) miss the same way, priced for a long list of features and integrations that no longer earn their place.

Focused and context-rich

What was needed was a focused tool that allowed all that context to live in the backlog and on the board. It needed to be human friendly and agent ready. Work was being delivered as fast as it could be defined; with agent-driven delivery, the friction in defining work had become the binding constraint.

So, I wrote Can: a lightweight Kanban board where the ticket is the definition of work.

The data model is deliberately small. Each ticket has a unique ID (like NOTE-16), a title, and a markdown description. Tags group tickets, comments carry the conversation, and the workflow is just the name and order of the columns on your board. That’s the whole model. There are no ticket types, because markdown covers it: a ticket can be an epic linking to the tasks it contains, a single task, or a note logged mid-delivery when an agent trips over something adjacent. A ticket takes that shape without anyone declaring it up front — no picking a type before you know what the work actually is. Can's own board is public if you want to see it in use: https://can.randomfact.com/randomfact/CAN

The small model is what lets the description carry everything else. Requirements, technical approach, decisions made along the way — all of it lands in one field, in one tool, in a format rich enough to be worth reading and plain enough to be worth writing. Most of the coordination burden that landed on the epic owner was reconciliation: making sure a change in one artifact reached the other three. With one artifact, there’s nothing to reconcile. Nothing to gather from Confluence, nothing to chase in Figma, nothing lost in translation between them.

Agents are first-class users rather than an integration bolted onto the side. The MCP server ships with usage instructions and an example skill (/can:pr, which takes a ticket, does the work, and opens the PR on GitHub). I use agents to build out the work plan as tickets; the same way we used them to draft the TDD and task breakdown at Great Expectations. When an agent picks up a ticket it gets the context itself, not a link to a page that links to another page.

Humans are first-class users too. The board is fast and good-looking: fly around with the keyboard, drag and drop, create tickets from your desk or your phone. Links and ticket IDs render the way you’d expect. Comments and change history are tracked on every ticket, so when an agent rewrites a description, you can see exactly what changed. If you’re shipping software at agent speed, give Can a try on your next product or team, and please let me know how it goes.