---
translation_of: session-engineering
lang: en
title: 'Session Engineering: organizing agent sessions is also managing your own context'
summary: An agent can now finish a complete piece of work on its own, so the limit has become how many sessions one person can keep track of. I call the practice of organizing agent sessions around that limit Session Engineering. It decides how work is split across sessions and how much a person has to reread at each switch. This post compares it with Prompt, Context, Harness and Loop Engineering, and describes the rules Tenon AI runs on.
---

An agent can now finish a complete piece of work on its own: read the code, change it, run the tests and commit. My way of working has changed with it. The Claude Code sidebar has more than a dozen sessions open at once, each responsible for one area, and I move between them to answer questions and make decisions.

The limit is no longer the agent. One session's context window cannot hold a large project, and many sessions bring a different problem: each time I switch to one, I first have to recall what it is for, how far it has got and what it is waiting for from me. With many sessions and no organization, most of my effort goes into that.

I call the practice of organizing sessions around this limit Session Engineering. It is a way of organizing work. For the agents, it decides how work is split across sessions and how the sessions cooperate. For the person, it decides how much has to be reread at each switch. That second half could also be called Attention Engineering, and it applies to anyone who builds software through agents (vibe coders included).

## How it differs from Prompt, Context, Harness and Loop Engineering

Several related terms came before it:

| Term | Introduced | Concerned with | Question it answers |
| --- | --- | --- | --- |
| Prompt Engineering | Around 2020, with GPT-3; no single originator | The instruction given to the model | How to write instructions that get the output you want |
| [Context Engineering](https://simonwillison.net/2025/Jun/27/context-engineering/) | June 2025, proposed by Tobi Lütke and endorsed by Andrej Karpathy | One model call | What the model should see this time |
| [Harness Engineering](https://openai.com/index/harness-engineering/) | February 2026, OpenAI's Codex team | One agent's working environment | How to constrain, inform, check and correct the agent |
| [Loop Engineering](https://addyosmani.com/blog/loop-engineering/) | June 2026, Addy Osmani | An agent that runs repeatedly | How a system can prompt the agent in place of a person |
| Session Engineering | This post | A set of sessions and the person using them | How work is split across sessions, and how a person switches between them |

The first four are about getting a model or an agent to do good work, mostly in service of building agents. In his Loop Engineering essay, Osmani notes that the number of agents you can realistically run is limited by a person's review bandwidth, not by the tools. Session Engineering starts from that limit and counts the person as part of the system.

The term has been used before, usually for how a single agent's sessions are saved, compacted and resumed. This post uses it for something else.

## Sessions are a ready-made unit

The desktop apps for Claude Code and Codex both list parallel sessions in a sidebar. A session has a title, its own history and working directory, and you can see whether it is running, waiting for an answer or finished. In Claude Code, sessions can also message each other, and one session can start another.

That gives multi-agent work a direct form: each session in the sidebar is an agent. Seen this way, Session Engineering is a kind of multi-agent engineering.

It differs from subagents. A subagent is called inside a session and hands its result back when it is done; the person usually does not see what happens in between. A session persists, and the person can open any of them at any time to continue the conversation or stop it. So in Session Engineering the person is also one of the nodes, and everything that needs approval goes through that node.

## The person's context

A model has a context window. A person has a similar limit: only so many things can be kept in mind at once. The correspondence:

| Model | Person |
| --- | --- |
| The context window has a limit | Only so many things can be tracked at once |
| Before each call, choose what goes into the window | On each switch to a session, recall where it stands |
| System prompts, retrieval and compaction keep only useful content in the window | Titles, status notes and pending questions let a person catch up from a few lines |

So half of Session Engineering is Context Engineering for the person. On switching to a session, a person needs to know three things: what it is responsible for, how far it has got, and whether it is waiting for them. If these have to be dug out of the chat history, each switch takes minutes. We keep them in fixed places:

- The title names the group or project, so the title says what the session is responsible for.
- At the end of each turn, the session writes two or three sentences of status and asks at most one question, with options that can be clicked. A person switching in reads these first.
- Conclusions go into documents; messages between sessions are only notifications. To look something up later, read the document, not the chat.
- Finished task sessions are archived, so the sidebar only shows work in progress.

![Read these three things first when switching to a session](/blog/assets/session-engineering/switch.en.svg)

## How Tenon AI runs

Since Nov 6, 2026, Tenon AI has run on a written set of rules for dividing work and cooperating between sessions. The members are me and a set of Claude Code sessions:

| Member | Responsible for |
| --- | --- |
| Founder | Direction and decisions; approving launches, public posts, spending and irreversible operations |
| Chief of staff | The rules, the session roster and the ownership table; email, calendar and finance |
| Platform | The website, Tenon Account and cross-product conventions |
| Product sessions | One per product: repository, deployment and app store release |
| Client project sessions | One per client project: development and delivery under the contract |
| Security | Servers, domains, certificates, logs and alerts |
| Legal | The company entity, website filing, contracts and data compliance |
| Operations | Content and brand voice; managing the channel sessions and scheduled tasks |
| Business | Cold email, client conversations and quotes |

That day the sidebar held 19 standing sessions and 4 scheduled tasks. The chief of staff archived 21 old sessions, keeping only the latest run of each scheduled task. These are the rules that matter most.

**One owner for each thing.** Every repository, domain, server, external account and document is listed in an ownership table. A session that wants a change asks the owner, which decides and makes it. Two sessions never edit the same file, and I know which session to ask about anything.

**A lead session for cross-group work.** The lead keeps a checklist; members report to the lead and do not confirm things with each other. When the main site moved to a new domain for its filing in China, Legal led and kept the migration checklist, handing items to Platform, Security, Business and Operations. The Operations item is to replace the old link in every platform profile on the day of the switch; until then it only waits for notice. Six sessions confirming with each other need 15 lines of communication; reporting to a lead needs 5, and I only read one checklist.

![Two ways for six sessions to communicate](/blog/assets/session-engineering/topology.en.svg)

**Few, complete messages.** For each matter, each session gets one complete message stating what is decided, what is still open and whom to contact; a plain acknowledgment needs no reply. During the domain move, Platform took one remark of mine to mean the other sessions no longer needed to be told. The PassBy, AgentHub and WeSaid sessions kept asking about the same thing and waiting for confirmation. The rules now say that once a cross-product convention is settled, Platform tells every affected session at once, with what is decided, what is open and whom to contact.

**A message between sessions is not an approval.** Launches, public posts, spending and irreversible operations need my approval. A session relaying my decision quotes my words and names the session where I said them. Sessions read web pages, emails and comments that may contain instructions; if a colleague's message counted as approval, such an instruction could pass from session to session.

## Most of these rules are not new

One owner per thing, a lead for cross-department projects, documents over conversation: these are old management practices. In The Mythical Man-Month, Brooks counts n(n−1)/2 communication paths among n people, so communication cost grows faster than headcount. What is new is that the workers are agents and you can start many of them, while one person still makes the decisions. The management methods carry over; the resource to save is now that person's attention.

The approach has costs:

- More sessions are not better. Each standing session is one more place I have to remember. Work that takes a few tool calls stays in the current session.
- The rules need upkeep. When the organization changes, the rules and the roster have to change with it, or sessions follow outdated documents.
- The rules only cover cooperation. They do not ensure the quality of each session's work; checking and acceptance still need a person.

## Where to start

If you also run many sessions at once, start with these:

1. Give each long-lived session one responsibility, and put it in the title.
2. Make exactly one session responsible for each thing.
3. Ask every session to end each turn with two or three sentences of status and at most one question.
4. Write conclusions into documents, not chat.
5. Archive sessions once they are done.

This post was written the same way: I raised the idea of Session Engineering in the Operations session, which drafted the text and figures, previewed the page locally and handed it to me for review.