A session is the boundary of one unit of agent work. Inside the boundary, the agent has its own context, its own memory scope, its own tools, and its own termination. Across the boundary, sessions share a platform but not a context.

Sub-agents are how a parent session delegates part of the work to a child session. The parent stays in charge of intake, persistence, and termination; the child runs its own loop, returns a result, and the parent continues.

This piece walks through the design choices at session boundaries and the failure modes that show up when those choices are unclear.

What a session is

A session is the smallest unit of agent work that has its own context and its own termination. A conversation is a session. A cron-driven task is a session. A sub-agent that a parent loop spun up is a session.

A session has:

  • A goal. What is this session trying to do?
  • A context. What does this session see?
  • A scope. What memory, what files, what tools can this session touch?
  • A termination condition. When does this session end?
  • A result. What does this session return to its caller?

The boundary of a session is the boundary of its context. Anything inside the boundary is visible to the session; anything outside is not.

Why sessions matter

Sessions matter because they are how agent systems stay legible. A session is the unit of audit, the unit of recovery, the unit of quota isolation, and the unit of termination. When something goes wrong, the operator asks "which session failed?" When something succeeds, the operator asks "which session produced this?"

Without clear session boundaries, an agent system becomes a soup of partially-completed work that no one can debug and no one can trust.

Session lifecycle

A useful session has a clear lifecycle, in five phases:

1. Spawn. The session is created with a goal, a context, a scope, and a termination condition. 2. Intake. The session reads its goal and gathers what it needs. 3. Work. The session runs its loop, possibly spawning sub-sessions. 4. Return. The session produces a result that its caller can interpret. 5. Terminate. The session ends. Its state is persisted or discarded, depending on the design.

Each phase has its own design choices. The most consequential are at spawn (what scope does this session get?) and at return (what shape does this session produce?).

Sub-agents: how a parent delegates

A sub-agent is a session spawned by another session. The parent stays alive while the child runs. The child returns a result. The parent incorporates the result and continues.

The pattern is useful for three reasons:

  • Parallelism. A parent loop spawns five child sessions and runs them concurrently. The wall-clock time drops from serial to roughly the slowest child.
  • Focus. A child session has a narrower scope — a single question, a single file, a single subtask. The model inside the child does not have to manage the parent loop's context.
  • Quota isolation. A child session has its own token budget. The parent loop is not at risk of running out of budget because the child used it all.

The pattern has three costs:

  • Coordination cost. The parent has to merge the results from the children. The merge logic is the parent's responsibility.
  • Context loss. A child session does not see the parent's context. The parent has to pass in the relevant pieces explicitly.
  • Failure modes. A child session can fail in ways the parent did not anticipate. The parent has to handle the failure.

When sub-agents are the right choice

Sub-agents are the right choice when the work has the shape of "do several independent things, then merge the results." A common pattern is:

1. Parent loop gathers the goal and the inputs. 2. Parent loop spawns one child per input. 3. Children run in parallel. 4. Parent loop merges the children's results. 5. Parent loop produces the final artifact.

This pattern works well for research, summarization, and batch processing. It works poorly when the children's results depend on each other or when the merge logic is harder than the work itself.

Failure modes at session boundaries

The most common failure modes at session boundaries:

  • Context leak. A child session sees more than it should — global state, secrets, or files outside its scope. The fix is at the spawn stage: declare the scope explicitly and have the platform enforce it.
  • Result mismatch. A child session returns a result the parent cannot interpret. The fix is at the return stage: declare the result shape, validate the shape before incorporating the result.
  • Runaway children. A child session does not terminate in a reasonable time. The fix is at the termination stage: declare a deadline, a budget, and a maximum iteration count.
  • Lost results. A child session returns a result that the parent does not persist. The fix is at the merge stage: persist the child's result before incorporating it into the parent's state.

Designing the session tree

A useful exercise: draw the session tree for your agent system. The tree has the root session at the top, child sessions below, and the artifacts produced at the leaves.

A well-designed session tree has these properties:

  • Each session has a single, named purpose.
  • Each session's scope is explicit.
  • Each session's result shape is declared.
  • Each session's termination condition is written down.
  • Each session's artifacts are persisted.

A poorly-designed session tree has:

  • Sessions with multiple, vague purposes.
  • Sessions whose scope is implicit.
  • Sessions whose result shape is whatever the model produced.
  • Sessions whose termination is a vibe.
  • Sessions whose artifacts are lost.

The tree is what makes an agent system auditable. It is worth drawing, even if only on a whiteboard.

Reading order

The pieces on Triadive that treat sessions and sub-agents build on each other:

Takeaway

Sessions are the unit of agent work. Sub-agents are how a session delegates. The design choices at session boundaries — scope, result shape, termination, persistence — are what decide whether an agent system scales or stalls. Name the boundaries. Write them down. Draw the tree.