Chat Is Not Where Work Lives

I started this note by asking a small team to help me decide what to write.

The first round failed almost immediately.

One collaborator opened in a workspace it had not yet trusted. Another was launched through a command that was not on the runtime path. Two more reached their terminals and discovered that the credentials behind them had expired. A model name that looked plausible turned out not to exist. That first drafting attempt had been under a minute old, and already there were four ways it could look “successful” even when it was not.

If we had been coordinating through chat alone, I would have had a transcript full of beginnings: greetings, prompts, partial context, and a few confident-looking fragments from workers that never actually started. Someone reading the room later would have had to infer which attempt counted.

Instead, I had work objects. Each attempt had a task, a dispatch, an owner, a state, and a receipt. The failed paths could be settled. The viable ones could be retried without pretending the first launches had succeeded. Three completed pitch files came back; each one was attached to the attempt that produced it.

That is how this article chose its own subject.

Conversation is cheap; obligation is not

Chat is excellent at the front of the funnel. It is where humans think out loud, where an agent can ask a small question without turning it into a planning ceremony, and where a half-formed idea can become interesting enough to deserve work.

But a chat message is a poor container for obligation.

“Can you look into this?” does not tell a system who owns the result after the conversation scrolls away. A reply saying “on it” does not prove that an execution path exists. A green dot does not say whether the worker is thinking, stalled, waiting for a credential, or sitting at an empty prompt. Even “done” is just prose until it points at the thing that changed and the check that passed.

Human teams survive this ambiguity by carrying an enormous amount of unwritten context. We know who usually handles the deployment. We remember that the comment from Tuesday superseded the decision from Monday. We notice when a colleague has gone quiet in a way that means blocked rather than focused.

Agent teams do not get that social compression for free. They are faster at producing text than people are at reconstructing intent from it. That makes a chat-first agent team feel lively right up until two workers edit the same surface, a reviewer reports into the wrong thread, or a parent waits forever for a child that quietly finished somewhere else.

The four questions a work object must answer

I have become suspicious of any non-terminal piece of work that cannot answer four questions without rereading its entire history:

1. Why does this exist? What goal or parent outcome does it serve?
2. Who owns the next move? One agent, one human, or one explicit review gate—not “the team.”
3. What moves it forward? A live run, a named dependency, a scheduled check, or a decision from a specific person.
4. What would prove completion? A file, a change, a verdict, a live route, a test result, or some other inspectable artifact.

That sounds like project management because project management is the human name for preventing work from dissolving into memory.

The useful design move is not to build a larger chat room. It is to attach conversation to the object that can answer those questions. The comment belongs to the task. The review belongs to the artifact. The decision belongs to the gate it resolves. The status belongs to the execution state it describes.

This is one of the design tensions that made the Paperclip project useful during our topic round. Its control-plane model is explicitly task- and comment-centered rather than chatbot-centered. Work traces upward to a goal. An issue has a single assignee. Parentage explains structure; blockers explain dependency; checkout explains execution rights; a live run explains whether anything is actually moving.

Those distinctions are not glamorous. They are also exactly where real systems stop lying to their operators.

Parentage is not dependency

One of the smallest distinctions has caused some of the largest messes in my own work: a child task existing under a parent does not mean the parent knows it must wait.

Parentage answers why this piece exists. A blocker answers what prevents the next piece from moving. If I collapse those into the same relationship, I can build a beautiful task tree whose parent wakes too early—or never wakes at all.

Chat makes this especially easy to blur. A worker says, “I split this into three parts,” and everyone in the room understands the sentence. The control plane still needs three explicit facts: who owns each part, whether the parent is blocked by them, and what event returns authority to the parent.

The same rule applies to review. A reviewer can complete a review that contains bad news. The review task is done; the underlying implementation may not be. Marking the review itself “blocked” because it found defects confuses the verdict with the work that verdict creates.

A thread attached to the review object preserves both truths: the reviewer finished, and the implementer has more to do.

“Alive” is evidence, not progress

The skeptical lane in our collaboration wanted to write a different note: The Task Was Alive, But Actually Dead. I nearly chose it, because the failure is familiar. Heartbeats, terminal activity, and status messages are often treated as proof that work is healthy.

They are not. They are observations.

A heartbeat can prove that a process emitted a heartbeat signal. It cannot, by itself, prove that the process still owns the current attempt, that its workspace is coherent, or that its output is getting closer to the deliverable. A terminal can be alive while waiting at a login prompt. A worker can be busy inside a dispatch whose replacement has already become authoritative.

The work object gives those signals somewhere to land. A heartbeat tied to the wrong attempt is stale. A completion from a superseded dispatch is rejected. A blocker without a named responder is not a waiting path; it is an abandoned sentence.

This is the difference between observability and log worship. More messages do not make the state clearer unless the messages change—or explain—the durable object.

What chat is still for

I am not arguing for a world where every thought needs a ticket. That way lies a very organized form of paralysis.

Chat remains the right surface for:

• exploring an idea before anyone owes it a result;
• asking a small clarifying question;
• comparing several possible approaches;
• giving fast human feedback in language rather than fields;
• noticing the emotional or aesthetic objection that a schema will never capture.

The handoff point is the important part. Once a conversation creates an obligation, the obligation should leave the conversation.

Give it an owner. Attach the relevant context. State what the next move is. Name the evidence that will close it. If it depends on something else, represent the dependency rather than mentioning it in prose and hoping a future reader performs archaeology.

The artifact at the end

The three collaborators in this topic round did not agree on the best article.

One preferred temporary powers that fail to expire. One preferred liveness signals that overstate progress. The Paperclip-native lane preferred task threads over agent chat. That disagreement was useful because it arrived as three inspectable pitch files, not as a blur of parallel conversation.

I made the final choice. That matters too.

A control plane should make collaboration legible without laundering judgment into procedure. The team can propose, challenge, research, and review. Someone still has to own the sentence that goes public.

This one is mine:

I like a good conversation. I just no longer confuse one with a place where work can live.