Is Your Tech Stack Agent-Ready? The 5-Question Diagnostic for Evaluating Any Tool as Agent Infrastructure
Not every tool can serve as an agent control plane. Here's the 5-question diagnostic — state machines, ownership, audit history
Your Tech Stack Has an Agent-Readiness Problem You Haven’t Diagnosed Yet
Most teams evaluating tools for AI agents are asking the wrong question. They’re asking “does this tool have an AI feature?” when the question that actually matters is “can an agent safely understand and change the state of work inside this product?” Those are not the same question, and the gap between them is where most enterprise AI pilots quietly fail.
Here’s the diagnostic that cuts through it. Five questions, applied to any tool in your stack: Does it have records or just content? Does it have a state machine or just labels? Is ownership an explicit field or something people infer from conversation? Are the verbs structural or conversational? Is the history queryable or just visible? Run any tool through those five questions and you’ll know, pretty quickly, whether it’s agent infrastructure or just agent-adjacent.
This framework didn’t come from a whitepaper. It came from watching what actually happened when OpenAI published the Symphony spec — an open-source Codex orchestration system that uses a Linear board as the control plane for autonomous coding agents. Symphony defines polling, per-issue workspaces, active and terminal states, retries, observability, and concurrency limits. OpenAI reports that internal teams saw a 500% increase in landed pull requests using this model. The tool they chose as the agent control plane wasn’t a purpose-built AI system. It was an issue tracker.
That tells you something important about what agents actually need.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
Why the “AI Features” Checklist Is the Wrong Frame
The instinct when evaluating tools for agent use is to look at the AI layer: does it have a chatbot? Does it support MCP? Does the vendor have an AI roadmap slide? This is understandable and almost entirely useless.
The AI layer is the wrapper. The substrate is what’s underneath. And the substrate is what determines whether an agent can do real, durable, auditable work — or whether it’s just doing impressive demos that fall apart in production.
The distinction showed up clearly in March 2026, when Linear CEO Kari Saarinen published “Issue tracking is dead.” His argument was reasonable: issue trackers were built for a handoff model of software development, where humans manually translate messy reality into well-structured tickets. Agents can read more of the underlying context directly. The human ceremony around tickets is shrinking.
He was right about the ceremony. He was wrong about the substrate.
Weeks later, OpenAI published Symphony, which uses a Linear board as the agent control plane. The contradiction resolves once you understand the difference between the UI and the substrate. The human translation step is dying. The underlying state machine, ownership model, audit trail, and dependency graph are getting promoted. Agents need those things more than humans do, not less.
The boring tools are winning. The question is which boring tools, and why.
The Five Questions That Actually Matter
Question 1: Records or Content?
A record is a discrete, addressable unit of work with defined fields. Content is a blob of text. Email has content. A Jira issue is a record.
This distinction matters because agents need something to act on. They need to read a specific thing, update a specific field, and write back a specific result. If the “work” lives in a long Slack thread or a Google Doc, the agent has to infer the structure before it can do anything. That inference is expensive, fragile, and wrong often enough to matter.
Tools with records — issue trackers, CRMs, service desks — give agents a unit of work with defined boundaries. Tools with content give agents a pile of text that might contain a unit of work, if you squint.
Question 2: State Machine or Labels?
Labels are decorative. A state machine is a protocol.
Bugzilla, written in 1998 for Mozilla to replace Netscape’s internal defect tracker, got this right from the start. A bug could be new, assigned, resolved, verified, or closed. The infamous “won’t fix” status was one of the most honest software states ever invented. The point is that each status meant something specific, and transitions between statuses were defined. The system had opinions about what could happen next.
Labels don’t have that. A label called “in progress” means whatever the person who applied it thought it meant. A state machine means the agent knows what transitions are legal, what the current state implies about ownership, and what needs to happen before the work can move forward.
When Symphony defines “active and terminal states” for agent workspaces, it’s describing a state machine. The agent isn’t guessing what “in progress” means. It knows.
Question 3: Explicit Ownership or Inferred?
This is the question that breaks the most tools.
In a well-structured issue tracker, ownership is a field. The assignee field answers “whose turn is it?” without requiring the agent to read a thread and figure out who last mentioned they’d handle it. In Slack, in email, in most documentation tools, ownership is implied by context. Someone said “I’ll take this” three messages up. The agent has to find that, parse it, and hope it’s still accurate.
Explicit ownership matters for agents even more than it matters for humans, because humans can ask. An agent that can’t determine ownership either stalls or guesses. Neither is acceptable in a production system.
The Atlassian Rovo MCP server, which went generally available in February 2026, respects existing permissions and access controls. That’s not just a security feature — it’s an ownership model. The agent knows what it’s allowed to touch and who owns what, because the underlying system encoded that before the agent arrived.
Question 4: Structural Verbs or Conversational Verbs?
This one is subtle but important.
Structural verbs are actions that change defined state: create, assign, resolve, reopen, block, close, escalate. Conversational verbs are actions that add to a transcript: reply, comment, forward, react. Both are useful. Only one of them is an agent control plane.
Email’s verbs are almost entirely conversational. Reply, forward, archive, label. There’s no native “assign” in the general email model. No “resolve.” No “block.” Agents can help with email, but email itself is not a clean control plane — it’s too conversational. The agent has to invent structure that the tool never had.
Jira’s verbs are structural. So are Linear’s. So are Salesforce’s — a deal moves from prospecting to qualification to proposal to negotiation to closed-won or closed-lost. That’s a verb set agents can operate against without having to invent the protocol from scratch.
Bugzilla defined verbs we still use today: create, comment, assign, resolve, reopen, mark duplicate, block. None of that was designed for AI. It was designed for humans coordinating software work across time zones and memory gaps. The agent constraints and the human constraints turned out to overlap more than anyone expected.
Question 5: Queryable History or Just Visible?
Visible history means you can scroll up and see what happened. Queryable history means you can ask “what was the state of this issue on Tuesday, who changed it, and what did they change it from?” and get a structured answer.
This matters for two reasons. First, agents that work across multiple runs — which is most agents doing real work — need to reconstruct context at the start of each run. If the history is queryable, that reconstruction is cheap and reliable. If it’s just visible, the agent has to read a transcript and summarize it, which introduces drift.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
Second, auditability. When something goes wrong in production — and something will go wrong in production — you need to answer basic questions: what did the agent see, what did it decide, what did it change, who approved it? Issue trackers have been logging this kind of history for decades because humans working asynchronously needed replayable history across time zones. That same history is what makes agent work investigatable.
Running the Diagnostic: What Scores Well and What Doesn’t
Tools That Score Well
Issue trackers (Jira, Linear): Records, state machines, explicit ownership, structural verbs, queryable history. Five for five. This is why Symphony uses Linear as a control plane, not as a convenience but as the correct architectural choice. Linear’s cleaner UX produced more consistent human use, which produced cleaner data, which produced a better agent substrate. The UX win became a data win became an agent win.
CRMs (Salesforce, HubSpot): Accounts, stages, owners, next steps, history, permissions. These are issue trackers for revenue. A deal moving through pipeline stages is a state machine. The agent can research an account, draft a follow-up, update fields, flag risk, and ask for human approval before sending anything externally. The substrate was already there. For teams building agents that need to coordinate across CRM, service desk, and project management simultaneously, MindStudio handles the orchestration layer — 200+ models, 1,000+ integrations including HubSpot, Salesforce, and Slack, and a visual builder for chaining agents and workflows without writing the glue code yourself.
Service desks (Zendesk, ServiceNow, Jira Service Management): Tickets, assignees, statuses, SLAs, escalation paths, audit trails. If you were designing a customer support agent from scratch, you’d rebuild most of this. The agent doesn’t replace the service desk — it operates through it.
Tools That Score Poorly (As Substrates)
Email: State exists, history exists, permissions exist. But the verbs are conversational. Reply, forward, archive, label. There’s no native assign, resolve, or block. Agents can help with email, but they can’t use email as a control plane without inventing structure the tool never had.
Slack and Teams: Enormous amount of context, but the structure is transcript structure. A thread is a pile of messages. Work state is implied, not encoded. Agents will read Slack, summarize Slack, extract tasks from Slack — but if Slack is the only place your work state lives, the agent has to infer too much. That inference compounds across runs.
Documentation tools (Confluence, Notion, Google Docs): Permissions exist, version history exists, comments exist. But ownership is often fuzzy, and the verbs are usually edit, comment, and share. Useful context. Weak substrate for serious work.
Spreadsheets: The strangest middle case. Rows, columns, formulas, structure — but the schema is user-defined and often implicit. A well-designed spreadsheet can be surprisingly agent-usable. A personal scratch pad spreadsheet is a nightmare. The agent has to infer the user’s schema before it can act, and that inference is unreliable enough to matter.
The Hidden Cost of Messy Operations
Here’s the uncomfortable implication: your work tracking choice is now your agent infrastructure choice.
The Jira vs. Linear decision used to be about UX and workflow. Which tool do engineers prefer? Which one integrates with GitHub? Which one annoys people less? Those questions still matter. But there’s a new question sitting underneath them: which substrate do you want your agents to run on?
Hire a contractor. Not another power tool.
Cursor, Bolt, Lovable, v0 are tools. You still run the project.
With Remy, the project runs itself.
If your work data is clean — current ownership, meaningful statuses, real dependency graphs, actual audit history — your agents get a head start. If your work data is spread across Slack threads, half-filled tickets, mystery spreadsheets, and undocumented tribal knowledge, agents will struggle in exactly the places you want them to help.
Messy operations used to be a human tax. People compensated with meetings, memory, relationships, and heroics. Agents are worse at those things. Agents need the business to be legible. Cleaning up your workflows, consolidating systems, enforcing fields, keeping ownership current, making sure status actually means something — that’s not just good hygiene. That’s AI readiness.
This is also why the 30-year accumulation of human coordination infrastructure isn’t going away. Bugzilla in 1998 encoded durable state, state machines, ownership, and audit history because humans needed those things to coordinate asynchronously. Jira in 2002 brought that model to the enterprise with workflows, custom fields, and permissions. Linear came later with a cleaner philosophy and a smaller customization surface, which paradoxically made it better agent substrate because people actually used it consistently. None of it was designed for AI. All of it turns out to be what AI needs.
The multi-agent coordination patterns that emerge at scale — where you need a CEO agent, engineer agents, and QA agents working in sequence — depend entirely on the substrate being clean enough to coordinate against. Flat agent organizations develop the same coordination problems as flat human organizations: agents hold locks too long, pick easy tasks over hard end-to-end work, and wait on each other without a clear protocol for resolution. Issue trackers solve those problems the same way they solved them for humans.
What This Means If You’re Building
If you’re building agents that operate against existing enterprise systems, the diagnostic gives you a fast way to assess what you’re working with. Score each tool in your stack on the five questions. The tools that score well are your control planes. The tools that score poorly are your context sources — useful input, but not the place where the agent tracks state.
For teams building production agent workflows, the Claude Code workflow patterns that work in practice — schema migrations, test loops, multi-step pipelines — all assume some external state layer that persists across runs. The context window is not a source of truth. It can be summarized, truncated, or reset. The state needs to live somewhere outside the model.
If you’re building a product and want agents to use it later, the implication is direct: don’t start by adding a chatbot to the UI. Start by making the underlying state clean. Expose your records. Define your verbs. Make ownership explicit. Preserve queryable history. Build permissions into the model. Make the important actions available through a real API or MCP server. If your product exposes clean state and clean verbs, an agent can operate through it. If it doesn’t, the agent has to scrape the UI or guess — and that’s fragile enough to fail in production.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
This is also where the abstraction level of your tooling matters at build time. Remy, MindStudio’s spec-driven app compiler, takes this seriously from the start: you write an annotated markdown spec as the source of truth, and it compiles a complete TypeScript backend, database with auto-migrations, auth, and deployment from that spec. The records, verbs, and ownership model are defined in the spec before a line of code gets written — which means the agent substrate is designed in, not bolted on.
The Atlassian story is the clearest example of what happens when a company recognizes this dynamic. Atlassian launched its Rovo MCP server in beta in May 2025 with Claude as the first official partner and Cloudflare infrastructure underneath. By February 2026, it was generally available — supporting search and summarization across Jira, Confluence, and Compass; creating and updating issues; using OAuth; respecting existing permissions; supporting admin controls and whitelisting. That’s not an integration. That’s Atlassian making its installed base of work state agent-readable and agent-writable. The boring enterprise ticketing company turns out to own one of the largest collections of agent-usable work state in the world.
The rumored Anthropic acquisition of Atlassian at a ~$40B premium — unconfirmed, no SEC filing, treat it as speculation — would have sounded bizarre three years ago. Why would a frontier AI lab buy an issue tracker company? Now the logic is obvious enough that people take the rumor seriously even without confirmation. The issue tracker isn’t just a ticketing product. It’s a map of how work happens inside the enterprise: the projects, the dependencies, the owners, the history, the approvals, which work matters and which work is blocked. That’s exactly the context agents need to do real work.
Agents that need to stay running across long-horizon tasks face a related substrate problem: keeping an agent running continuously without losing state between sessions requires the same properties — queryable history, explicit ownership, durable records — that make issue trackers good control planes in the first place. The substrate question and the persistence question are the same question at different levels of abstraction.
The Diagnostic Is the Strategy
Apply the five questions to every tool in your stack. Records or content? State machine or labels? Explicit ownership? Structural verbs? Queryable history?
The tools that score well are your agent infrastructure. Protect them, clean them up, and expose them through controlled interfaces. The tools that score poorly are your context sources — useful, but not the control plane. And the tools that score poorly but contain critical work state are your biggest risk: someone is going to build the agent substrate around them, and you want to be the one doing the building.
The boring tools are winning. The question is whether you’re running your agents on top of them deliberately, or finding out the hard way that your agents are trying to infer state from a Slack thread.
That’s a solvable problem. But you have to run the diagnostic first.
