One person, one deliverable, one working day with an agent. The structure is there whether or not anyone builds a system — and seeing it changes how you run the day.
Most of the pieces on this site describe systems: how an orchestrator curates what a model sees, who holds control flow, what belongs in a workspace. This one describes a session — one person sitting down with an agent to produce one deliverable. No pipeline, no architecture, nothing deployed. The claim is that the same structure the system pieces describe is present in the session anyway, and that a person who can see it works differently: they know what to gather, what to write down, what to delegate, and what each step should leave behind.
The example is a client proposal, and it runs the length of the piece.
You run a consulting practice. On Tuesday you had a scoping call with Meridian, a logistics company that wants help consolidating three warehouse systems it acquired along with the companies that ran them. The call went well. They asked for a proposal by Friday: scope, approach, team, timeline, price.
The proposal will be built from material that already exists. The call transcript — fifty minutes, in which their VP of operations described the three systems, the integration that failed last year, and what they need to see by Q2. The email threads — four months of back-and-forth, spread across your account, and buried in them things the call never touched: a budget guardrail the CFO mentioned once in March, a stakeholder who was cc'd on everything and spoke on nothing, a promise a colleague made in April that the proposal had better not contradict.
And it will be shaped by material from outside this deal entirely. The last six proposals your firm sent, two of which closed. The proposal template. The notes on what makes a proposal land. And the mistakes log — the file that says discovery was underquoted on two engagements running, and that no phase-two date should ever be committed before phase-one discovery ends.
You open the agent in an empty folder and start.
Three kinds of material are now in play, and it pays to name them, because they behave differently for the rest of the session.
Inputs are what this deliverable is made from: the transcript and the email threads. They are specific to Meridian and useless for any other client. They carry the facts.
Grounding is what shapes how the deliverable gets made: the prior proposals, the template, the best-practices notes, the mistakes log. None of it mentions Meridian. All of it is reusable, and all of it carries the standards.
Instructions are what you tell the agent to do right now.
Every request you make of the agent during the session is a merge of the three: the facts come from the inputs, the structure and standards come from the grounding, and the instruction names the step.
This is worth internalizing because it is a diagnostic. When a step produces weak output, one of the three was thin. A pricing section that never mentions the CFO's budget guardrail: the inputs never reached the step — the guardrail is in a March email the agent never saw. A pricing section that underquotes discovery again: the grounding never reached it — the mistakes log was sitting in another folder. A beautifully grounded section that answers the wrong question: the instruction was vague, and the agent satisficed. Same weak page, three different repairs, and the three-way split tells you which one you owe.
The session starts with gathering, and “gathering” is doing more work in that sentence than it appears to. For every source of material, you make the same small decision, and it comes in two forms:
inputs/. The six prior proposals are scattered across old project
folders; copy them into grounding/prior-proposals/. The mistakes
log lives in a notes app; it is half a page, so paste it into
grounding/mistakes.md and be done.tools/.These are the same act at two depths. Both give the agent access. Copying is fast, and what you get is a snapshot — right for the transcript, which will never change. A tool costs more to set up and stays live — right for the email account, which will have new threads in it by Thursday. Choosing per source, rather than defaulting to one or the other, is most of what separates a tidy setup from an afternoon of re-gathering later.
The gathering ends with a file: project.md. A plain statement of what
we are producing, from what, under what constraints. For Meridian it is short —
the deliverable and its sections, the Friday deadline, a list of the materials and
where each lives, and the constraints that must survive every draft: pricing
respects the CFO's guardrail until told otherwise, discovery is never quoted below
the floor the mistakes log set, no phase-two dates.
It is written first, and it earns its position the same way the overview document in
The Living Workspace does: every
later instruction can be shorter because the goal is already on disk, and every
later dispute about scope has a text to check against. “Draft the pricing
section” means one thing in a folder with a project.md and
something much vaguer in a folder without one.
proposal-meridian/ ├── project.md the goal: what we are producing, from what, by when ├── inputs/ │ ├── transcript-07-28.md Tuesday’s scoping call │ └── emails/ pulled by the tool below — four months of threads ├── grounding/ │ ├── prior-proposals/ the last six that went out │ ├── template.md the house structure │ ├── best-practices.md what makes a proposal land │ └── mistakes.md discovery floor · no phase-two dates ├── kb/ built during the session — starts empty ├── tools/ │ └── query_email.py written on day one, improved in a sidebar └── drafts/ the proposal takes shape here
inputs/ and kb/ retire
with it, and grounding/ and tools/ move on to
the next one.
Look at what the folder now contains: inputs, grounding, tools, and a written goal. That is a workspace. You did not set out to build one, and no part of the setup felt like architecture. It is simply what gathering looks like when the results are organized in a directory an agent can operate in — which is the quiet advantage of doing this work through a coding agent rather than a chat window. A chat accumulates context that evaporates when the tab closes. A folder accumulates artifacts.
With the workspace in place, there is a question worth asking before any real work: could a single instruction turn these inputs and this grounding into a satisfactory proposal? Written out, it would say something like: using the transcript, the emails, the template, and the prior proposals, draft the full Meridian proposal; respect every constraint in project.md.
Sometimes it is worth actually running it, just to see the shape of what comes back. Twenty minutes later you have a document, and the document is informative in both directions. The approach section is surprisingly close — the transcript covered that ground well, and the template held it in shape. The pricing section is confident, generic mush — because the thinking that prices an engagement lives in your head and in patterns scattered across six prior proposals, and no instruction said so.
But the point of the question is not the attempt. It is a sizing question: how much of the path can be handed over at once? The answer depends on how good the grounding is, how messy the inputs are, and how much judgment the deliverable needs. Early in a project the honest answer is usually “not yet” — and that answer determines the structure of the day. If one instruction is enough, the session is one delegation and one review. If it is not, you keep the outer sequence yourself and delegate bounded steps. The rest of the session is what that looks like.
You pick the piece of work that matters most right now. The pricing section is the heart of the proposal and the place the last two mistakes were made, so it goes first. And immediately the step exposes missing material: pricing depends on what Meridian has said about budget, scope, and timing across four months of email, and none of that is in the folder yet in usable form. So the step begins with more gathering, and the work settles into a chain:
inputs/emails/. A few hundred messages land as files.kb/meridian.md — every decision, constraint, commitment, and
stakeholder, each with a pointer to the thread it came from. This is where the
March guardrail surfaces, and the April promise, and the fact that the silent
cc is the CFO's chief of staff.Each step got a bounded instruction, a specific slice of inputs, and the grounding that step needed. None of them was asked to do the whole job.
Notice what happened between steps 2 and 3: the knowledge base, which was an output, became the input of the next step. This is the engine of the chain. Each step’s product lands in the folder and is the material the step after it works from. The folder is the state, and it only grows.
The discipline this enforces is easy to miss because the folder does it for you. A few hundred emails would not fit in a context window, and stuffing even a fraction of them in alongside the template and six prior proposals would bury the step in noise. The knowledge base is the compression: built once, checked once, and from then on every step that needs what the emails said reads twelve hundred words instead of four months of correspondence. Nothing is re-derived; the distilled artifact carries it forward. This is the same prescription the system pieces make — externalized state, curated context per step — arrived at by no other means than working in a directory.
Some outputs flow the other way. Drafting the pricing section settles questions
that are not facts about Meridian at all: how a section opens, how email evidence
gets cited, how price is framed against milestones. You have the agent record
those decisions in project.md, next to the constraints, and every
remaining section is drafted against them. That output carries standards rather
than facts — the session has produced its own grounding.
So outputs feed later work in two directions, and the two deserve separate names. An output that carries facts into the next step is the pipeline effect: it runs step to step, and it is what makes the chain a chain. An output that settles standards for the steps after it is the workspace effect: it runs across the whole session, and past the end of it. The pipeline effect gets this deliverable made. The workspace effect makes the next one cheaper.
The chain is not the whole session. Around it there are sidebars — small exchanges that never touch the deliverable directly — and they divide into two kinds that do different jobs.
Before committing to the extraction step, you asked a cheaper question: size up the emails first. How many threads, over what date range, and which ones look substantive? The answer came back in minutes — three hundred forty messages, about sixty that matter, the rest scheduling and pleasantries — and it changed the plan: extraction would go thread by thread through the sixty, not message by message through the pile.
That is a scouting sidebar. Its output is not deliverable material and never will be. It exists to inform your next orchestration decision, and it is cheap precisely because a rough answer is fine. A session run without scouting is a session where every delegation is a leap of faith about what the material even contains.
The other kind of sidebar changes the workspace instead of the plan. The first version of the email tool queried by sender, and the scouting pass showed why that was wrong: the thread where scope was agreed happened between your colleague and Meridian's procurement lead, and neither of them was in the original query. So you have the agent rewrite the tool — thread-level, date-filtered, matching on the domain rather than a list of names.
The pricing step did not require this. You did it because the want will recur — this
week, for the rest of the engagement, and for every future client whose
correspondence lives in the same account. The improved tool sits in
tools/ where every later step, and every later project, can use
it.
The distinction is worth keeping because the two kinds justify different spending. Scouting is cheap and always worth it. Building costs real time in the middle of a deadline week, and the test is recurrence: build when the want will come back, and not before. A session with no building sidebars produces only the deliverable. A session with the right ones produces the deliverable and a workspace that makes the next deliverable cheaper — and over enough sessions, that difference compounds into the gap between someone who uses an agent and someone who has an operation.
Ask the question this site keeps asking — who decides the next step — and the answer for this session is: you do. The agent performed every step, but the sequence — pull before extract, extract before draft, scout before committing — lived with you, and you held it in the softest possible form: in conversation, revisable by talking.
That is not a deficiency of the session. For work being done for the first time, it is the correct arrangement, because early on flexibility is worth more than any guarantee. But watch what happens when the deliverable type recurs. The extraction instruction that worked gets saved into the folder, and the second proposal reuses it: the step is now written down — a skill. The email query was rewritten as a program on day one: that step is enforced — a tool. Piece by piece, the parts of the session that prove themselves harden, and what you hold in conversation shrinks to the parts that still need judgment: which client, which emphasis, whether the price is right.
Seen from this angle, the session is the front end of the lifecycle those pieces describe. Prompt, then skill, then tool is not a program you decide to follow. It is what naturally happens to any step you find yourself performing for the third time — provided the session leaves artifacts behind, which is exactly what the workspace is for.
The proposal goes out Friday. That is the first product, and the one you sat down for.
The second is the workspace: the organized inputs, the knowledge base, the improved
email tool, the project.md whose goal section is spent but whose
structure is not. The next proposal does not start from an empty folder. It starts
from this one — copy it, swap the inputs, keep the grounding and the tools — and
the setup that took a morning takes minutes. The grounding got better too:
Friday’s proposal joins prior-proposals/, and whatever this deal
teaches joins the mistakes log — the same workspace effect that ran inside the
session, now one project wide.