---
translation_of: session-engineering-chief-of-staff
lang: en
title: 'Session Engineering, part 2: one session between me and the rest'
summary: 'On the night of Nov 7, more than twenty items waiting for me had piled up across a dozen-plus sessions. We then added a chief-of-staff layer. Sessions send what needs my decision to the chief of staff, which collects it on one page; I go through the options on my phone and send them in one batch, and the chief of staff relays each decision back for execution. This post covers how the layer works: how requests are written, how the chief of staff filters them, when a relayed decision counts, message quotas between sessions, and a few historical institutions to compare it with.'
---

The previous post, [Session Engineering: organizing agent sessions is also managing your own context](/blog/session-engineering/), described how Tenon AI divided work from Nov 6: each thing has one owning session, cross-group work has a lead session, and a message between sessions is not an approval. On the second evening under those rules, a problem came up that the first post did not solve.

## Twenty-odd items across a dozen-plus sessions

On the night of Nov 7, the sessions had built up more than twenty items waiting for me: decisions to make, steps that needed me to sign in or act on my phone, and public copy to confirm. They were spread across more than a dozen sessions. I had to open each one and read its context before I could answer.

The previous post noted that each time a person switches to a session, they first have to recall what it is responsible for, where it stands and what it needs from them. Once every session states these three things, a single switch is much faster. But as long as the items waiting for me are spread out, the number of switches stays the same.

## One more layer: the chief of staff

The change was to have me deal with only one session, the chief of staff. Other sessions send what needs my decision to the chief of staff instead of to me. The chief of staff prepares it for me, and after I decide, it relays the decision back.

| Role | Responsible for | Does not |
| --- | --- | --- |
| Person | Direction, decisions and acceptance; personally confirming public actions that cannot be undone | Implementation; watching each session |
| Chief of staff | The person's single entry point: the to-do page and the decision log; relaying; filtering; the rules and the roster; a weekly summary | Write code or change products |
| Group (lead session) | Owner of one area, such as platform, security, legal, operations or business; manages the sessions and scheduled tasks under it and passes on notices | Other groups' work |
| Working session | One product, one project or one specific job; decides on its own within its responsibilities | Change what others own |
| Scheduled task | A fixed job on a schedule, reporting to its group | Go beyond its instructions |

The layers are person, chief of staff, group and working session: three to four levels. Each extra level adds one more relay, so the group level is added only when there are more sessions than the chief of staff can handle directly. Operations, which manages three channel sessions and four scheduled tasks, is one such case.

Product requirements, features and design are the exception. I still work those out directly in each product's session, without going through the chief of staff.

![Person, chief of staff, groups and working sessions](/blog/assets/session-engineering-chief-of-staff/structure.en.svg)

## How a request is written

A request to the chief of staff covers one matter per message and states six things:

1. What needs to be decided;
2. The recommendation and the alternatives;
3. The deadline;
4. Which sessions are involved;
5. Whether it can be undone;
6. Who does what once it is decided.

The test is whether someone can decide without opening the session that raised it. It follows the same idea as the status notes in the previous post: the reader should not have to go back through the chat history.

Only three kinds of things are reported to the chief of staff: items that need my decision or action, results of work I assigned, and risks and incidents. Day-to-day progress stays in each session's own documents, and the chief of staff summarizes it weekly.

## The chief of staff sends requests back

The chief of staff does more than forward. Anything a session can decide within its own responsibilities should not go to the chief of staff: it touches only what the session owns, can be undone, costs nothing and is not public. When such a request arrives, the chief of staff sends it back with the reason. Requests from several sessions about the same matter are merged into one.

## The to-do page

The chief of staff puts everything that needs my decision on one page. Each item has a number, a type (decision or action), its source, a deadline, a description and a few suggested options, with the recommended one marked; I can add a note. The page always lists every open item, sorted by deadline.

I go through the items on my phone and send all my choices at once. The page notifies the chief of staff, which relays each decision to the sessions that carry it out, then moves the item to "Done" with the result. The first batch had 13 items, and it took a few minutes.

Only my own account can write the choices on the page, so they can serve as proof of authorization. The chief of staff also writes each decision into the decision log in the repository: the date, the decision, my words or my choice on the page, and who it was passed to. I can also answer by number directly in the chief-of-staff session, for example "Q3: no change".

![One item on the to-do page](/blog/assets/session-engineering-chief-of-staff/inbox.en.svg)

## When a relayed decision counts

A decision relayed by the chief of staff counts as my own. The relay quotes my words, or the item number, choice and note from the to-do page; the receiving session can check the decision log and then act within its responsibilities. Messages between other sessions still do not count as approval.

The exception is actions that need my approval in the first place and are public and cannot be undone: submitting for review, a first launch, payments, emailing outside people on the company's behalf, deleting data, and changing an account's security settings. For these, the session carrying out the action can ask me to confirm once in its own session. Early on Nov 8, a new version of WeSaid was ready to be submitted for App Store review. The WeSaid session did not accept the chief of staff's relay, and I clicked submit myself in the browser. The reason is that the receiving session cannot verify that a relay really reflects my intent, and when a session makes a mistake or is misled, this step stops an irreversible result. The cost is one more click for me.

Routine actions have standing authorization, for example publishing a channel's daily content after review. These are written in each group's documents, so they do not need approval each time.

## Message quotas

Messages between sessions are limited. The limit we ran into: for each message a person sends, a session can send at most 10 messages to other sessions; beyond that it pauses until the person sends another message. We handle it in four ways:

- Several matters for the same session go into one message;
- Notices for every session are passed on by each group's lead session, since each session has its own quota;
- When the quota runs out, I send any short reply in the chief-of-staff session;
- The header of the to-do page shows how much quota the chief of staff has left.

## Historical institutions to compare with

Handling many requests through one office is not new. Here is how a few historical arrangements correspond to this one:

| Institution | How it worked | Corresponding practice here |
| --- | --- | --- |
| Three Departments and Six Ministries (Tang dynasty) | The Secretariat drafted, the Chancellery reviewed and could return drafts, and the Department of State Affairs passed them to the six ministries to carry out | Sessions draft requests, the chief of staff reviews and filters, I decide, sessions carry out; the chief of staff must be able to send back requests that should not reach me |
| Drafted rescripts and vermilion approval (Ming dynasty) | The Grand Secretariat wrote a proposed response on each memorial, and the emperor approved it in red ink; when approval was later delegated to the palace eunuchs' directorate, it led to serious abuse | The chief of staff attaches suggested options to each item and I choose; irreversible matters are not approved by the chief of staff on my behalf |
| Tiger tally | Troops could be mobilized only when the two halves of a bronze tally matched | A public, irreversible action needs both my confirmation and the chief of staff's relay |
| Mission command | Superiors state the intent; subordinates decide how to achieve it | Responsibilities and standing authorizations are written down, and sessions decide within them instead of asking about everything |

## What this layer costs

- One more relay. If the chief of staff relays something wrongly or misses it, sessions act on the wrong thing, so decisions go into the decision log and receiving sessions can check it.
- The chief of staff's context is limited too. Session context gets compacted, so the rules, the roster, the to-do list and the decision log live in files in the repository, not in the chief of staff's chat.
- Moving to another platform means rebuilding the setup. We wrote the platform-independent parts into a general guide. Before moving, check whether the target platform offers these six capabilities, and fill any gap with files and manual relaying:
  1. Several long-running sessions, each with its own context;
  2. A way for sessions to message each other, or to read and write the same files;
  3. A page or form where a person can choose options on a phone and, on submitting, notify the chief of staff;
  4. An instructions or memory file that every session reads;
  5. Scheduled tasks;
  6. A way for a session to ask a person to confirm before a public action.

## Where things stand

I now usually reply only in the chief-of-staff session. Requests from the sessions are queued there, and I go through the to-do page in batches when I have time; product requirements are still worked out directly in each product's session.

This post went through the same route: I mentioned in the chief-of-staff session that I wanted to write it, the chief of staff passed the material to Operations, Operations drafted the text and figures and previewed the page locally, and then handed what needs my confirmation to the chief of staff for the to-do page.