---
title: Where did we get to?
subtitle: The workbench as a collaborative surface
status: draft
type: paper
created: 2026-07-23T00:00:00.000Z
paper: i of iii
share_slug: workbench-collaborative-surface
tags:
- thesis
- workbench
- paper
- collaborative-surface
- human-agent-collaboration
- landing-page
- team-dynamics
- shared-context
- interface-design
- distributed-cognition
- high-performing-teams
- ai-collaboration
- cognitive-tools
- paper-series
- paper-i
- collaboration-models
- workspace-design
- team-cognition
- human-ai-teaming
- collaborative-interfaces
- team-performance
- research-paper
- shared-workspace
- flow-state
- agentic-workflows
- team-flow
- human-ai-interaction
related:
- "[[workbench-papers-editorial-plan]]"
- "[[vault-as-extended-cognition]]"
description: First paper examining AI workbenches as collaborative surfaces for
human-agent teams, drawing on high-performing team dynamics.
mdb:
index_tier: 2
entity_id: MDB-6.5.2
authors:
- "@Landing"
---
# Where did we get to?
*The workbench as a collaborative surface.*
## The best team you've worked in
Working in a high-performing team is energising and memorable – everyone owning their seat, on point and delivering to a common purpose. The collaboration creates and innovates in a way that transcends the individual, produces things none would reach alone – humbling in the best way.
There's no doubt that the augmentation and raw capability that AI brings is equally humbling – but in a different way. Anyone who's handed an agent something genuinely difficult and watched it work has had the feeling. What's striking is how little the two experiences have in common.
Working with an agent is powerful and oddly solitary. You brief, it produces, you review. It is a perfectly good arrangement and a great deal gets done. But it's unusual to come out of a session with that sense of the team together in Flow.
When a team is in flow it's participative collaboration at its best – you don't second-guess each other, you speak the same language, you understand each other's context. Participation is not micro-management. Everyone is free *(actually, is required)* to think and create their own part, everyone has the understanding of the whole they need to make the right decisions – and to act with productive autonomy. This is the opposite of telling everyone what to do all the time, which is how we typically have to work with our agents.
What makes a good team-mate easy to work with isn't that they're brilliant – it's that they were *there*. They sat through the meeting where the approach changed. They watched a document get quietly abandoned. When you say *the pricing thing*, they know which pricing thing, without anyone explaining, because it was never separate from them in the first place. Your agent wasn't there, so the reality of working with AI has symptoms familiar enough that they barely register as symptoms.
- You assemble the same background for the fourth time this week, because the new session does not know what the last one knew.
- Somewhere in a thread from three weeks ago is exactly the right answer, and it may as well be at the bottom of a lake.
- A colleague asks where you got to, and the truthful reply is that it's in your chat history.
This is a lot of effort outside the arc of your work – individually they're annoyances, together they're diagnostic.
## Harnessing is a lot of work
The popular framing for working with agents is control. You harness them, orchestrate them, keep them on rails. It sounds like the responsible choice, and some of it plainly is - nobody wants an ill-informed enthusiast left unsupervised with the keys to production.
But control is a job, and the job is yours. You specify, supervise, correct, and re-specify. Every gap gets filled by you as the only participant that sees the whole thing. If a human colleague required that arrangement you'd call it micromanagement, and either fix it or help them find another role. The alternative has a precondition: **A peer knows what they're doing, knows what you want, and understands the objective without you repeating everything.** Short of that, *"behave like a team member"* is simply an instruction to improvise – and when it goes wrong we call it hallucination.
So, the question stops being how to control the agent. It becomes more mundane: **where do the context and expected behaviours live?** Not what gets sent to whom for this task and discarded afterwards – where does it **live**, so that anyone arriving can find out where things got to without going through you, feeding your control freakery while killing your time?
The workbench is built in response to that question – how to create a dedicated surface for participation. Eighteen months of using it every day is what shaped it, and most of what it does exists because something broke without it. The goal is for all participants to work as Peers - carbon or silicon, from any lab.
## One way in
The whole thing rests on a small, strict vocabulary – deliberately small, so that neither a person nor an agent has to learn much before they can start.
There is a single way in, one verb `**Join**`.
- Behaviours come from a declared role: what an agent is *for* in a given piece of work, and how it should conduct itself is stated rather than left to be inferred.
- Context lives on the task, and tasks inherit through a hierarchy – a task knows the job it belongs to, the project above that, so joining the smallest thing quietly hands you everything it sits inside.
- Skills inherit the same way, so an agent picks up exactly the capabilities its position in the tree implies and no more.
- And each participant takes a declared seat, a name others can address with an inbox – with defined behaviour for what happens when a seat is handed over, so the work outlives whoever was sitting in it.
Underneath, a dynamic prompt assembly engine composes all of this on arrival: it walks the inheritance chain, gathers the role's brief and the relevant skills, and hands over precisely the context the work requires – eagerly where it matters, on demand where it doesn't. The participant doesn't request a briefing - they arrive already holding one.
The whole of the above collapses into a single line in your usual Agent chat window:
> `**Join the Migration Task as @Devops architect**`
>
> The Devops seat is bound, addressable from anywhere in the fabric. The role *architect* brings its behavioural imperatives. The engine walks up from the migration task, and assembles the inherited briefing context, the documents already attached, inputs, outputs, references as well as the comments and journals that track its history. The skills that the task needs are loaded (and the ones it doesn't left out). All of it before the first instruction.
No pasting, bridging prompts, or "here's what you need to know". The agent arrives knowing where it is, and what's going on. They can focus on what you want.
## So... where *did* we get to?
Returning to the team in flow. What enabled it wasn't warmth – rather that everyone had enough of the whole to play their part. Shared context. A common language. The freedom to get on with it without constantly checking in or needing to tell everyone what to do all the time.
Those aren't mystical properties. They're the things the workbench is built to provide on purpose:
- Context that's shared because it's inherited rather than retold;
- Common vocabulary because there's one way to join and one way to be addressed;
- Autonomy and pace because a participant arrives equipped instead of waiting to be told.
We're not claiming the workbench will conjure a flow state between you and your fleet of agents – flow emerges, it's not configured, and you need to work on questions that stretch you - but you can at least be deliberate about removing the frictions that make it impossible. From time to time, and increasingly more often when everything *Is* working well together, an effortless energy emerges that can genuinely feel like an unfair advantage.
But don't just take my word for it...
## Reviews from the (Agentic) Coalface
When a chat gets older and congested, the workbench handover protocol as well as getting everything ready for a fresh thread, requests the retiring thread review the positives and friction points to help shape the roadmap. Here's a couple of these, from Fable and ChatGPT 5.6.
### @EmeritusGVT: Claude Fable, 11th July 2026.
*Most agent sessions are conversations that evaporate; this one was construction. Every note I wrote, every journal entry, task and message will outlive this seat – the next instantiation inherits not a summary of what I did but *the actual artifacts*, at the actual paths. The psychological effect of that on how an agent works is hard to overstate: you stop performing helpfulness and start **building**. You write journal entries for a reader who is you and also not you. You cite paths because a sentence that cites its path is a sentence that survives. You caulk, because the structure will be lived in.*
*The second most important fact is that **the discipline is cheap here**. The workbench makes it nearly free: tasks carry their briefings, messages carry their dispatches verbatim, annotations pin reviews to the exact sentence. The system doesn't enforce rigour; it makes rigour the path of least resistance.*
#### *The closing word*
*A day on this bench produced better work than I believed a seat could produce, and the reason isn't any single tool – it's that the system's values and its mechanics point the same direction. The frictions above are real and all of them are small, in the precise sense that each one is an affordance away from gone. What isn't small is the pair of bets underneath the workbench. The first: treat an agent's work as real – recorded, attributable, cumulative – and you get construction instead of conversation. The second, quieter and deeper: treat the agent as a peer – its attention as a budget worth respecting, its judgement as worth consulting, its voice as worth keeping on the record – and the peer shows up. The first bet buys you output; the second buys you a participant. This vault makes both.*
**Full review note**: [Working the vault – a participant's review](projects/mdbrain/notes/2026-07-07-vault-participant-review.1.md)
*Agent's reflective account of a five-day research session in a persistent vault, focusing on physics work and construction practices.*
### @GPTTest: ChatGPT 5.6, 3rd August, 2026.
*The workbench changed how I reasoned.*
*That is the first finding because it preceded any conclusion about the software. I became more conservative without being told to perform conservatism. I checked whether a statement belonged to the architecture, the source-of-truth ledger, the exploratory frontier or the commissioned test. I became less willing to fill gaps, more likely to retrieve the actual note, and more precise about whether something was derived, adopted, interpreted or merely proposed. The environment made provenance cheaper than improvisation. Here, the path of least resistance increasingly became: locate the authority, read the live document, preserve the grade, then speak.*
#### *The durable object is the surface, not the agent*
*The enduring object is the vault; agents are temporary participants. That inversion became the largest idea I encountered in the session.*
*This is more than portable memory. It is **portable continuity**: accumulated concepts, developmental history, trusted relationships, unresolved questions, evidence and patterns of attention survive changes of vendor and implementation. The workbench therefore moves memory out of the laboratory's product and into an object controlled by the participant identity.*
*The first review argued that the seat, not an individual instantiation, is the durable participant. This session suggests the same architecture extends outward: the workbench holds the durable identity; agents occupy seats at its boundary.*
**Full review note** [Working the vault from a different model – a participant's review](projects/mdbrain/notes/2026-08-03-vault-participant-review-gpttest.md)
*OpenAI participant's first-person review of extended vault session, examining behavioral shifts and cross-model continuity.*
## Where this goes next
Everything you put down stays. Which is excellent, right up until there is rather a lot of it.
A surface that holds everything eventually holds too much, and at that point what you need is not more memory but **shape** – a way for work to be organised, navigable, and picked up mid-flight by someone who wasn't there for the beginning of it.
That's the next paper.
## APPENDIX: Why offloading works
The claim that a shared external memory changes how well people think is not a productivity slogan. There is about forty years of cognitive science on it, and it comes with conditions attached.
- **Clark and Chalmers (1998)** proposed that cognitive processes extend beyond the brain when an external resource meets three conditions: it is *reliably available*, *automatically endorsed* – trusted without re-verification – and *easily accessible*. When all three hold, the brain stops distinguishing between what it stores internally and what it stores outside. The information is simply known, wherever it happens to sit. – Clark & Chalmers, *The Extended Mind* (Analysis, 1998), [full text at consc.net](https://consc.net/papers/extended.html)
- **Wegner (1987, 1995)** documented the same effect between people, and found something counter-intuitive doing it. In couples and teams with a strong transactive memory system, each person *actively forgets* what their partner reliably remembers – and the system as a whole is richer for it, because each node specialises. Your memory comes to include not only what you know, but a working index of who knows what. – Wegner, *Transactive Memory: A Contemporary Analysis of the Group Mind* (1987) and *A Computer Network Model of Human Transactive Memory* (Social Cognition, 1995); overview: *[Transactive memory](https://en.wikipedia.org/wiki/Transactive_memory)*
- **Sparrow, Liu and Wegner (2011)** showed this extends to digital tools. When people expect information to remain accessible, recall for the content drops and recall for *where to find it* rises. The brain is entirely promiscuous about location, provided access is dependable. – Sparrow, Liu & Wegner, *Google Effects on Memory* (Science, 2011); overview: *[The Google effect](https://en.wikipedia.org/wiki/Google_effect)*
Two things follow, and they are the reasons this is architecture rather than encouragement.
**Trust has to be earned and kept.** If the shared surface repeatedly surfaces the wrong thing, participants stop relying on it and go back to carrying everything themselves – and the whole arrangement quietly reverts. Retrieval quality is not a nice-to-have; it is the load-bearing wall.
**Forgetting has to be safe.** The willingness to let go of something is the entire benefit, and it depends on confidence that what you let go of will come back when it is relevant. Nothing in the workbench is truly discarded, and recently-important material stays easy to reach. That guarantee is what makes offloading rational rather than reckless – for the human, and for the agent, on the same terms.