It’s Monday. Someone messages you: “Hey, quick one — can you catch me up on where we landed with the Foo project?” You spend twenty minutes piecing it back together. You do it four more times this week. A contractor joins on Wednesday and you do it for them. Then you spin up an AI agent on a piece of the work and you have to do it for the agent, except now you can’t talk — you have to type it out, or skip it.

That last one is the giveaway. The catch-up has been broken for a long time, but it’s been a slow leak. The agent makes the leak visible.

Agents can’t sit through your standup

This is the new force, and it’s what changes the math. The people who need to be caught up on a project are no longer all biological. The AI assistant you ask to draft the spec, the agent that triages your inbox, the junior teammate whose first move is to ask Claude what’s happening — they all need the same context, and none of them can sit through a meeting that already happened. They can’t read the room of a hallway conversation. They can’t infer from tone. They can only read.

If your project state lives in someone’s head and gets rendered verbally on demand, it is, for the agent, not state. It doesn’t exist. You can give an agent every tool in the world and it will still produce nonsense, because the input it actually needs — what is happening on this project, what’s open, what was decided, what changed — was never written anywhere it can find.

That’s the loud version of the problem. The quiet version has been with us for decades.

The 2005 baseline

“Let me catch you up” used to be cheap because the conditions were forgiving. Teams were smaller. Most people sat in the same room. Most people ran one or two projects at a time, not eight. State lived in maybe two places — a wiki and somebody’s inbox. The verbal handoff was lossy then, too. You just didn’t notice, because you didn’t have to do it that often, and a small drift in someone’s mental model rarely surfaced before the project ended.

What changed, besides the agents

Parallelism, distribution, tool sprawl.

Parallelism: people run more projects in flight at once. Each one needs its own catch-up.

Distribution: nobody’s in the same room. Catch-ups happen across time zones, in DMs, in async chunks where you can’t read the room.

Tool sprawl: project state is scattered across eight surfaces — chat, tickets, design tool, repo, docs, your own notebook. There’s no single place that’s authoritative, so the catch-up becomes the only place it converges: in someone’s head, for a few minutes, then it evaporates.

We already capture. We just can’t find anything.

Here’s the cruel part. Most teams have already paid for capture. Meetings are recorded. Transcripts are auto-generated. Notes get taken. Docs get written. Decisions get memo’d. The volume of project context we produce per week is enormous — probably an order of magnitude more than 2005.

It just lives on the wrong axis.

The recording is attached to the calendar event it came from. The note is in the doc the meeting organizer created and shared with whoever happened to be on the invite. The decision is in a Slack thread that scrolled away. The memo is in a folder organized by quarter. None of this is anchored to the project. It’s anchored to the moment it was created.

So when someone asks “what happened with the Foo project last month,” the captured material is technically there — but to find it you’d have to search across the calendar, three doc tools, two chat surfaces, and your own scattered notes, then mentally reassemble a narrative from the fragments. Nobody does this. It’s faster to ask. So we ask, and we get the verbal catch-up, and the captured material rots unread.

Captured-and-unfindable is functionally the same as not captured. Worse, in a way: it’s a constant unpaid debt that everyone knows is there and nobody can collect on.

The compounding cost

Every verbal catch-up creates a divergent mental model. You explain the project to Alex on Monday slightly differently than you explain it to Priya on Tuesday, and slightly differently again to the contractor on Wednesday. None of these renderings are wrong. None of them are the project, either. By the end of the week there are five drifting versions of the same thing, and the only one that gets reconciled is the one that produces a bug in production.

This isn’t a meetings problem. It’s a where does the project live problem. If the project lives in your head and gets re-rendered verbally each time someone needs it, you are running a system whose canonical state is not durable, not searchable, and not visible to anyone who isn’t currently talking to you. That was tolerable in 2005. It’s broken now.

The structural alternative

Project state has to live somewhere external to anyone’s head, anchored to the project rather than to the moment of capture. Written down. Ordered. Searchable. The catch-up becomes a link, not a meeting.

This isn’t novel. Every long-lived engineering org eventually invents some version of it: design docs, status threads, project channels. What’s new is how badly we need it now, how much captured material we already have lying around unused, and how poorly the existing tools serve the actual job. Status threads decay in chat. Design docs go stale the moment they’re approved. Tickets describe work, not narrative. Meeting recordings live in the calendar. None of these is a place where the project’s running state lives.

What this looks like in practice

This is what we built workjournal for. One journal per project. Updates accrue in order. The journal is the place the project lives — what’s happening, what was decided, what’s open, what changed. When someone needs to be caught up, you point them at the journal. When an agent picks up the thread, it reads the journal. When you come back to a project after two weeks on something else, you read it yourself.

The point isn’t that journaling is novel. The point is that “let me catch you up” was always a bug. The agent didn’t introduce the bug. It just made it impossible to keep ignoring.

A workspace owns journals. A journal holds entries. An entry has a title, a summary, a body, a timestamp, and a tag for who wrote it (which agent, which person). That’s it. No threads. No statuses. No labels. No sub-entries. No parents and children. No custom fields. No roles matrix.

That answer surprises people, because every team that’s tried to share project context has started by trying to model the project relationally. Tickets get statuses, owners, parents, children, sprints, labels, custom fields. The schema reflects how the team thinks. Then how the team thinks changes — a new workstream shows up, a process gets renamed, two efforts merge — and the schema doesn’t change with it.

So the schema rots. And the data starts lying.

The taxes that structure makes you pay

The structured shared-context tool only stays useful if someone curates it. Curation is a job. On most projects, no human’s job description is “keep the knowledge base tidy.” The slot exists, but nobody is paid to fill it, so it doesn’t get filled — and the sidebar that hasn’t been touched in six months becomes the canonical version of what the team is working on.

There’s a second tax that’s harder to see. Even when someone is curating, the cost of placing things in the right place is paid every time anyone writes. Did this decision belong in “Architecture” or “Tech debt”? Is this research note a child of the original spike or a sibling of the current ticket? The schema asks the writer a question every time they sit down. The writer pays the question. Most of the time, the writer pays it badly, or skips writing.

There’s a newer tax on top of those two: maintaining the agents that promise to do the organizing for you. Use a sub-agent to file this in the right page. Use a watcher that re-tags entries when a project pivots. The agents work, mostly. They drift, sometimes. The cost of keeping them aligned with how the team currently thinks is, again, a job.

And here’s the part that took us a while to see: agents don’t actually need the structure. The reason structure exists in the first place — to help a human navigate a corpus by hierarchy — is mostly a human-cognition crutch. Agents are good at handling dense, flat, chronological text. Often they’re better at it than at navigating a tree someone built six months ago and then renamed.

What append-only buys you

A journal is the opposite of curation. Entries are append-only. You don’t update old ones; you write new ones. Yesterday’s decision and today’s reversal of it both live on the timeline, in order, with their reasoning. The trail is the data.

Reading a journal is search + summary, not navigation of a hierarchy. You ask for “what we decided about the migration,” and the relevant entries come back, with their context, in chronological order. There is no sidebar to keep tidy because there is no sidebar.

This shape is what makes the journal good for agents specifically. Word search works on it now; semantic search is coming, and it works cleanly on a stream of entries because there’s no nested object graph to rank inside. An agent doesn’t need a tree to navigate; it needs text to retrieve. A journal hands it text.

The things we deliberately didn’t build

Some features get asked for, and don’t get built, because they would make the journal harder to read for the next person or agent that opens it.

• Threads. Conversations aren’t the unit. A decision is the unit; the conversation around it is best summarised into the entry, not preserved as a tree of replies that scrolls past.

• Statuses. Workjournal is not a tracker. The project’s tracker — your tickets, your sprint board — stays the source of truth for what’s open and what’s done. The journal is for what was decided and why.

• Sub-entries and nesting. A flat timeline is a feature. Nesting is a curation tax — every entry asks “where does this go?” and most writers answer wrong, or stop writing.

• Rich-text formatting outside the web app. Markdown is portable. Every agent surface reads and writes plain text. A rich-text-only entry is an entry an agent can’t write.

(There are features that aren’t on this list because they’re roadmapped, not rejected: tags and labels are coming; finer-grained roles arrive with Pro. The bar isn’t “never build it” — the bar is “build it only if it doesn’t make the read pass slower.”)

What you get instead

What the small data model gives you, in the order you feel it:

• Writing is cheap. There’s no “where does this go” question, no field that has to be filled, no parent to pick. You write a title and a body. The journal accepts it.

• Setup is cheap. Create a workspace, create a journal, invite a collaborator. There’s no schema to design first, no taxonomy to commit to before the team has had a chance to disagree about it.

• Reading is fast. A new teammate or a new agent opens the journal and finds the project — chronologically, in their own words. There’s no map to learn before they can navigate.

The real tradeoff

This isn’t a free lunch. A flat journal is less intuitive and less structured for a human reader than a curated knowledge base is. A well-tended one, where someone is genuinely keeping the sidebar honest, is more pleasant to skim than a stream of entries.

Two things are true that swap the calculus.

The first is that the well-tended knowledge base is rare. Most teams have an aspirational one and a real Slack. The journal lives where the real work lives.

The second is that the journal is perfectly readable to agents. Word search lands precise hits today; semantic search lands fuzzy ones soon. Either way, the agent that picks up the project tomorrow doesn’t care that the structure isn’t pretty — it cares that the text is there. And the cost of writing into the journal is so low that the journal stays current in a way the knowledge base doesn’t.

What you actually need

Your project doesn’t need a complex knowledge base or a structured second brain. It needs a place where agents can write and read information fast.

That place is a journal. The shape is the point.

— The workjournal team

Try workjournal on your next project — free for solo use, Plus when you start collaborating, at workjournal.pro. One OAuth click connects it to Claude, ChatGPT, Perplexity, and 30+ other agents.

The decisions are made. The architecture is sketched. The library is vetted. The teammate’s question is answered. The work is done — most of it. What’s missing isn’t the work; it’s the trail of it.

Take a Tuesday we hear about a lot. A developer starts a new feature in Claude Code in the morning. The conversation builds up a clear picture of the architecture they’re after. Laptop closed. On the walk, they have an idea about a tricky migration; they think it through with ChatGPT on their phone. By lunchtime there’s a plan that quietly contradicts the one Claude Code landed on three hours earlier — and neither agent knows about the other’s session. After lunch, Perplexity gets a question about whether the third-party library they’re about to depend on is still maintained. Perplexity reads nothing, knows nothing, returns what it can find. Useful, but starting from zero again. By Friday, a teammate joins for a pair session and gets the briefing — verbal, partial, off the top of someone’s head. Half a day on the catch-up. The other teammate, in another time zone, never gets it at all.

Three agents. Two humans. One project. None of them sharing state.

The problem isn’t that any individual agent or any individual teammate is bad. They’re all very good at their jobs. The problem is that the project’s context — the decisions, the rationale, the research, the open questions, the things that just happened — lives in five places that don’t talk to each other. The human in the middle is the only thing connecting them, manually, from working memory, badly. The result is the modern tax on multi-agent, multi-person work: every new session and every new collaborator starts the project from zero.

The fix is structural, not behavioural. It is not “keep a journal” — that frames it as a personal practice, and the problem isn’t personal. The fix is to give the project a place where its context lives, and to make sure everything that touches the project, agent or human, can read and write there.

When the project has that shared place, everything else gets cheaper. The brief is written once at the top of the project and every new agent reads it before it starts. The teammate who joins on Friday opens the same surface and has the rationale for last Tuesday’s decisions. The agent that picks up the work in the next session writes back what it found, what it changed, what it ruled out. The morning briefing meeting that used to happen — badly, in five different chat windows and one Slack thread — turns into a thing the project itself remembers.

This publication is the operating manual for that. Not personal-journaling. Not productivity theatre. The unsexy version: how to run a project so that the next person — or agent, or future-you — walks in and knows where it is.

A few things you’ll see here over the next few months.

Operating Notes. How real teams run projects across multiple agents and multiple humans. Onboarding a new collaborator without burning a day. Handing off work between agents — Claude Code → Perplexity → ChatGPT → human — without losing the thread. Provenance: who or what wrote that, and why it matters. The patterns that scale across two-person side projects and ten-person teams.

Tactics. Templates and prompts. The shape of an entry an agent can act on. The minimum viable project brief that a new agent reads first. The decision-log format that holds up across a team and a quarter. The end-of-session prompt that captures what a teammate would want to know.

Field Notes. Dispatches from building workjournal, the shared project repository (in journal format) that connects Claude, ChatGPT, Perplexity, Cursor, and a few dozen other agents to one shared backend. We built it because we needed it, and we use it every day. This section is the public version of why and how — what we shipped, what we got wrong, and what we’re learning from teams running it on real projects.

If your week has any of “I’ll just remember it,” “it’s in Slack somewhere,” or “let me catch you up” in it, this is for you.

The cadence is one essay a week, Tuesdays. Reply to any of them — we read everything.

Brief once. Continue everywhere.

— The workjournal team