Rails for the Agent
In my last post, I described the frustration of working with an AI that forgets. You’re mid-build, in flow, and suddenly the model loses the thread. I called it a fracture in the flow—because that’s exactly what it feels like. Recovery can be slow, and the outcome is often messy or broken.
The problem is the context window, a kind of short-term memory that limits how much the model can pay attention to at once. When the conversation gets too long, earlier details fall away. The model drifts. Things come undone.
I started wondering whether that kind of fracture could be prevented—or at least reduced. Not just patched over, but redesigned from the ground up. What if there was a way to give the AI something to hold onto? A shared reference that persisted even as conversations changed?
That question led me to try something simple: treat the project management tool as a second layer of memory.
In software teams, tools like Linear already help maintain continuity across people, features, and time. I started using it not just to manage my own work, but to guide the AI. It became a kind of long-term memory layer—something that could hold what the model is likely to forget.
The PRD, tasks, constraints, and decisions all lived there. Linear gave me a way to store context externally, so the agent could reorient itself even after a chat reset. Instead of rebuilding context from scratch, we had a shared source of truth to work from—something I could build on across features and phases without losing the thread.
The Working Model
Here's what the process looks like in practice. The steps are simple, but they work together to reduce drift and preserve continuity:
1. Start with a shared understanding
I begin by defining the goal with the agent. We talk about what we’re building, why it matters, who it’s for, and what success looks like.
2. Capture constraints early
I provide the relevant context: architecture, tech stack, known limitations, design system principles. These aren’t just references—they shape what’s possible and prevent misalignment later.
3. Write the PRD together
The agent drafts the initial PRD. I ask it to highlight assumptions, risks, or unclear areas. We iterate until there’s a clear, usable spec.
4. Create a phased implementation plan
I ask the agent to break the work into high-level phases, then divide each phase into small, scoped tasks. The PRD and architecture are referenced constantly throughout.
5. Push the plan into Linear
I forked and extended a Linear MCP Server to bridge my work between Cursor and Linear. The agent uses it to create projects, upload PRD docs, generate and update issues, fetch workflow states, and add comments. This gives the plan a persistent home and provides a structured place for the agent to store and retrieve context as it works through the project.
MCP References
6. Execute one task at a time in Cursor
I pull one phase into a new chat, keeping the context tight. Each task is scoped small enough to avoid drift, but still meaningful. Cursor rules help the agent interact smoothly with Linear through the available tools. For example, I instruct Cursor to always read the architecture docs (ADRs) and fetch status updates or workflow information as needed. See my full list of rules at the end of the post.
7. Validate the work and check it back in
Once a phase is complete, I ask the agent to audit its work against the original plan. I manually review the result, test it, and then mark the issue as done in Linear.
Why This Matters
This isn’t about productivity for the sake of it. The deeper goal is continuity. The ability to keep moving forward without having to start over every time the AI hits its limit.
By using Linear as a kind of long-term memory, I’ve started to create a working model that’s resilient to context loss. It keeps the structure, the intent, and the decisions in one place. And that’s what allows me to build across multiple phases and features with confidence.
It also creates a shared surface for collaboration. The AI doesn’t just generate code—it works from shared goals, validates against criteria, and checks its progress like any teammate would. I still do the final review, but the loop is tighter and more aligned.
Most importantly, it gives me space to think and build without constantly managing the fragility of the conversation.
What I’m Still Figuring Out
There’s still a lot to learn. I’m curious how this holds up as projects grow or when the architecture shifts midway. I’ve started experimenting with agent roles using Cursor rules, like assigning tasks for code review, security scanning, or design system validation, to see if it helps produce more reliable outcomes. I’ll share more on that as I go.
Even with its imperfections, this feels like the beginning of a usable model. It builds on habits that are already familiar—structure the work, plan before building, and validate along the way. The part that feels new is the layer above the code. It captures intent, decisions, and the patterns shaping the system as it evolves. That’s where the receipts live.
For teams, and especially for 0-to-1 builders, this offers a way to manage complex projects while keeping the work grounded. When the agent loses context or starts to drift, the system gives it a path back. Over time, that structure becomes a growing trail of validated context. The agent doesn’t need to remember everything, because the shape of the work is already there to guide it.
Appendix: Full List of Cursor Rules Used
1When using the `mcp_linear_search-issues` tool:
2- Always include the project context if known: `project:"<PROJECT_ID>"`
3- For title prefix searches, use: `title:"<prefix>"`
4- Combine filters with spaces, e.g.: `project:"<PROJECT_ID>" title:"<prefix>" <keyword>`
5
6
7When using `mcp_linear_update-issues` tool:
8- Before you update, go into "product management" mode and verify that the completed task satisfies all of the requirements have been completed
9- If the task requirements are not complete, complete them exactly as specified
10- If the task requirements are met, create a use the `create-comment` tool to create a comment on the issue with a validation report
11- Write any tests required for the work created in the task (skip e2e tests) see @06-testing.md for details
12- Run the tests and make sure they pass
13- Update the status to 'Done'
14
15When using `mcp_linear_view-issue` tool:
16- if you're implementing an issue, be sure to follow the instrucitons in the issue with MAXIMUM PRECISION, do not overlook the instructions
17
18
19When you start on a new issue from Linear:
20- Update the status to 'In Progress'
21- be sure to read any documents referenced in the issue. Docs are found in /docs
22
23If you need to update the issue state or status and do not know the stateIDs:
24- use the `mcp_linear_list-workflow-states` tool to get the stateIDs if you
25