Technical delegation is not a new source of authority
A primary agent may ask another agent to research a dependency, modify a component, validate a result, or operate a specialized tool. The handoff is technically useful because it distributes work. But the parent agent’s ability to send a task does not give it the power to invent a broader enterprise mandate for the recipient.
Authority originates in an accountable source: an approved objective, owner, policy, assignment, or other enterprise mandate. Each delegate acts under a derived portion of that mandate. The delegation must remain traceable to the source, and every proposed effect must still be supported by the authority that reached the acting agent.
Begin with the parent mandate
The parent mandate should identify the objective, accountable sponsor, authorized action space, relevant targets, duration, required approvals, and prohibitions. It does not need to predict every internal plan, but it must be concrete enough to decide whether later proposed effects serve the approved work.
Without that foundation, delegation amplifies ambiguity. Each child receives a task phrased by another machine, possibly after several transformations. A clear parent mandate gives the system a stable reference against which those tasks and their resulting actions can be evaluated.
Delegated scope should be explicit and narrower
A delegation record should state which part of the objective is assigned, which operations and resources are in scope, how long the assignment lasts, and what evidence the child must return. The delegate does not inherit every capability or choice available to its parent merely because both participate in the same workflow.
Authority may contract through delegation. A release agent authorized to coordinate a release might delegate documentation work without delegating merge or deployment authority. A specialist may be able to recommend a configuration change but not apply it. Narrow scope reduces ambiguity and makes downstream decisions easier to explain.
Descendants must inherit prohibitions
Constraints that protect the original mandate cannot disappear when the topology changes. If the parent is prohibited from touching production secrets, changing identity policy, or operating outside a named repository, a descendant cannot shed those limits by accepting a narrower-sounding subtask. Delegation should preserve applicable upstream prohibitions through every generation.
This is non-amplification: a delegate cannot legitimately produce authority its parent did not possess. The rule matters even when a descendant uses different credentials or a specialized tool. Technical power at the next hop does not enlarge the enterprise mandate behind the work.
Retries and topology changes need continuity
Multi-agent systems retry failed work, replace unavailable agents, split tasks, combine results, and alter plans. These changes can be operationally correct while weakening authority lineage. A retry may occur after a time boundary, use a different tool, or target a new resource. A replacement agent may receive an artifact without the constraints under which it was created.
Each material topology change should preserve or re-evaluate the applicable mandate, delegated scope, prohibitions, and evidence. A retry is not automatically authorized because an earlier attempt was. The system should decide whether the proposed action is still the same authorized effect or a new action requiring fresh evaluation.
Evidence lineage makes delegation reviewable
The authority record should connect sponsor, mandate, parent agent, child agent, delegated objective, constraints, proposed action, decision, and observed result where available. This is more than a technical trace of messages. It explains why the descendant was empowered to act and which limits survived the handoff.
Evidence lineage also supports targeted incident response. Investigators can determine whether a problematic effect came from an invalid mandate, an overbroad delegation, a lost prohibition, a stale retry, or an execution path outside coverage. An authority chain of custody turns those questions into inspectable records rather than inference from scattered logs.
Agent swarms make the control problem harder
At larger scale, an agent may not know every descendant created on its behalf. Work can fan out through queues, shared files, orchestration frameworks, and independently scheduled processes. The resulting topology is dynamic, while enterprise mandates are usually defined in organizational systems that do not model every machine relationship.
That is why AI swarms create an authority problem, not only a coordination problem. Enterprises need authority that travels with work, contracts through delegation, retains upstream prohibitions, and produces lineage at consequential control points. Coordination decides who does the task. Authority decides whether any participant may create the proposed effect.
Delegation policy should be enforceable at consequential effects
A well-formed delegation record is valuable only if later control points can use it. When a descendant proposes a merge, data export, payment, or infrastructure change, the workflow should be able to recover the parent mandate and test the descendant’s scope. Passing a free-form task description without a stable authority reference makes that decision fragile.
Organizations can phase this architecture in by requiring lineage for a small set of high-impact operations. Missing lineage becomes an exception, while ordinary internal coordination can remain lightweight. As coverage grows, the same model can span more agents and tools. The enduring rule is that technical delegation routes work; it does not create business authority.
NEXT STEP