Why We Built Pins as Project Working Memory

When we designed pins, we made one small but important decision: they should not be a global memo list.

A global memo list is straightforward to build. Give the user a text box, save a title and body, sort by time, and call it “later.” Many tools work this way, and it is enough for ordinary saved notes.

AI coding exposed a different problem. The hard part was not finding a place to write things down. The hard part was reopening the work days later and discovering that the context had scattered. The screenshot was in chat. The failing command was in terminal scrollback. The product judgment was inside a review. The next action existed only in someone’s short-term memory.

The note still existed. The work was no longer resumable.

So we designed pins as working memory beside the project. A pin is not primarily a saved idea. It is a small piece of context that future work can continue from.

The ceiling of interactive agents

Interactive sessions are the natural starting point for coding agents. Open a terminal, describe the task, wait for the agent to work, review the result, and steer the next turn.

That pattern works well with one or two sessions. It is direct, and it keeps human judgment in the loop.

It starts to strain when parallelism increases. In our use, once a person is watching three to five agent sessions, the expensive part is no longer the agent runtime. It is the context switching. You have to remember which session belongs to which worktree, where each one is stuck, whether the output is trustworthy, and whether it discovered a follow-up that should not be lost.

Those follow-ups are awkward. They are often real, but not important enough to interrupt the current task.

For example:

• An agent fixing a test notices that a name is misleading its callers.
• A reviewer sees a narrow-screen layout issue that is outside the current PR.
• A user sends a screenshot while you are focused on another branch.
• An experiment fails, but the reason it failed may be useful later.

If those fragments stay only in chat history, they become part of a timeline instead of part of the work system. A timeline is good at reconstructing a conversation. It is a poor handoff surface. A future engineer, a future agent, or you next week should not have to read dozens of turns to infer where the work should resume.

The shift: preserve recovery points

We eventually reframed the problem: pins are not for saving content. They are for saving recovery points.

That changed the product shape. A recovery point needs at least four things:

• Context: why this exists.
• Evidence: screenshot, log, link, or reproduction condition.
• Expected outcome: what “done” means.
• Next action: where a human or agent should begin.

That is why a weak pin should not stop at:

Fix login

A better pin looks more like this:

Title: Fix the login button on narrow screens

Context: Reproduced in a 13-inch window. The primary button touches
helper text below it.

Evidence: Screenshot attached.

Expected: Keep stable spacing when the English copy wraps.

Next action: Ask an agent to locate the layout component and test the
narrow viewport.

The point is not heavier note-taking. It is cheaper recovery. The more complete the context, the less the next worker has to ask, search, or guess.

Why pins live near the project

External todo tools can store tasks, but they are usually too far from the worksite.

When it is time to act, you still need to find the repo, branch, terminal, screenshot, discussion, and current code state. For ordinary todos, that is friction. For agent workflows, it affects quality. Thin context makes agents fill gaps by guessing.

In TermCanvas, pins are project objects. They sit alongside repos, worktrees, terminals, and agent sessions. When we open a project, we do not want the pin list to answer “what did I save?” We want it to answer:

• What is still open in this project?
• What can be handed to an agent?
• What needs human judgment first?
• What is already closed?
• What did we deliberately decide to drop?

That makes pins closer to a lightweight control surface. They are not a full project management system, and they should not replace an issue tracker. They cover a smaller, earlier, more contextual layer: things that are not worth doing right now, but would cost judgment to rediscover later.

When a pin is handed to a terminal or agent, it stops being a note and becomes input. The title, body, links, screenshots, and next action become the starting point for the prompt. The agent does not have to infer intent from the current chat. It receives a defined recovery point.

Decentralized working memory

Pins have another property that is easy to miss: they do not require all work to move into one central system.

Teams already have mature surfaces for permissions and collaboration. Linear can manage product work. Feishu and Notion can hold documents and discussion. GitHub Issues can stay close to code and PRs. Each system has its own permissions, notification behavior, and organizational habits. Pins should not reimplement all of that.

The better pattern is to let those tools keep doing what they are good at: deciding who can see something, who can edit it, what should be shared, and what belongs in the formal workflow. Pins handle a different layer: the local insight, evidence, and next action that appear while you are doing the work.

That gives pins two useful shapes.

One is personal. Local pins can hold judgments that are not ready to publish: why an experiment failed, why an agent result was not trustworthy, or why a design direction is not worth pursuing yet. Those insights may not belong in a team system immediately, but they change what you do next.

The other is collaborative. A pin can reference Linear, Feishu, Notion, or a GitHub Issue and bring shared context into the local execution surface. It can also start locally, get refined with evidence and a next action, and later become an external task or comment. The external system remains the permission and sharing surface. TermCanvas carries the execution context.

When this pattern is combined with Hydra headless, pins can also become part of a centralized pipeline. A team can run headless agent workflows in the cloud that pull from shared task systems, create or update pins, dispatch agents, and write back results. Local TermCanvas sessions can still participate in the same loop: you can take over a pin, add evidence, change the next action, or send a local finding back into the cloud workflow.

This is neither purely local-first nor purely centralized collaboration. Pins are portable working memory. They can stay on one machine or connect to team systems. They can support private judgment or become input to an agent pipeline.

The workflow changes

Once preserving and handing off context becomes cheap, the way teams treat small work changes.

We no longer have to choose between two bad options: do it immediately and interrupt the current task, or ignore it and probably lose it. Pins create a third option: fix the context in place and keep moving.

This matters most when multiple agents are running. Boundaries become more important than speed. The current task should stay narrow. Side discoveries should be preserved instead of smuggled into the current PR. Otherwise one change slowly accumulates test fixes, UI cleanup, documentation edits, and product judgment until it becomes hard to review and hard to revert.

Pins give those side discoveries a cheap place to go:

• Follow-ups from review can become independent work.
• Failed experiments can keep their conclusion instead of leaving only a vague memory that they were tried.
• User feedback can stay attached to the screenshot until the right agent picks it up.
• A half-formed refactor can be explored later without turning into a large change immediately.

The deeper change is psychological cost. Small signals that were not worth recording before become worth preserving because they can actually be resumed. Resumability changes what we are willing to try.

New problems

Pins introduce new problems.

The first is accumulation. If everything becomes a pin, the list turns into another inbox. We do not want pins to become a black hole for “later,” so they need explicit states: open, done, and dropped.

done means the loop is closed. dropped is just as important. It means we deliberately decided not to continue. Many ideas are not worth doing, but it is still useful to preserve why. Otherwise the same idea reappears weeks later and costs another round of judgment.

The second problem is scope. Pins are not the right place for large plans, cross-team scheduling, compliance approvals, or roadmap work that needs long-term tracking. Those should still live in Linear, Feishu, Notion, GitHub Issues, docs, or project management systems. Pins fit the layer between “not now” and “do not lose this”: screenshots, traces, reproduction steps, follow-ups, and small agent-sized tasks.

The third problem is quality. A vague pin only delays the ambiguity. We encourage writing pins as handoffs, not just titles. They do not need to be long. They need to be specific enough to restart work.

What we learned

AI coding changes development from single-threaded execution into multi-threaded coordination. You are not only writing code. You are managing agents, worktrees, terminals, PRs, test results, and unfinished judgments.

In that workflow, the scarce resource is not another window. It is resumable context.

Pins fix context beside the project so a future human or agent can continue from a clear recovery point. They are not bookmarks, and they are not a project management system. They are working memory: light enough to capture quickly, structured enough to restart work, close enough to the project that context does not scatter during the next switch, and open enough to connect with shared tools and cloud agent pipelines.

That is the standard we use for pins. Their value is not saving more things. Their value is making important small work depend less on human short-term memory.