root@construct:~/rants/agent-context-boundaries$
<-- back to /rants
2026-06-21//OPINION

Too much context for every agent is poor delegation

Dumping every workstream's context into each agent is a poor way to delegate. I want agents collaborating, and I still want to know which job each one received. Mixing everything together as a precaution pushes the decision about relevance onto the next executor.

Tools that generate reusable skills from demonstrations raise a concrete choice: what should travel with a capability when it leaves the first execution? Repeating a procedure does not always require carrying every conversation that led to it.

I want to separate the capability description from the material for the current execution. The skill explains when it applies and which criteria guide the work. The task supplies the context needed to use it now. That separation makes it easier to check whether the answer came from the current request or from old information that travelled along without a reason.

History can be necessary. An earlier decision might rule out a solution that looks good when reading only the latest request. In that case, I want to carry the decision and explain its consequence. Cutting context at any cost causes rework too: an agent repeats a settled investigation or proposes something incompatible with a known constraint.

The boundary I propose is straightforward to enforce: each relevant piece needs a reason to accompany the task. When information is missing, the agent should name the concrete doubt. When material changes no decision, I can remove it in a later comparison while keeping the expected result constant.

I will organize context handoffs around the delegated objective and leave history available when there is a reason to consult it. If using a capability requires supplying every conversation from every workstream, the boundary is still poorly defined.

Too much context for every agent is poor delegation | The Broad Way