# From Conversation to Delegation
# Book: Language
# Chapter URL: https://programmer.ie/books/language/32-chapter/
# Prose fingerprint (sha256, normalized): 5c009be89a017f9cb926fcf37109960b1b0da7f34e7361376c3632e86ecf37d1
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

Iris has decided what she wants to do about another part of the Berlin trip: the hotel. She keeps the flight trade-off described in the last chapter, but gives a different instruction for the stay: Book one refundable hotel within these limits. You do not need to bring the purchase back to me unless the terms fall outside them. That is a decision to delegate one bounded operation, not an inference from earlier bookings. The price, distance, dates and meaning of refundable must be sufficiently specified in the grant the system actually enforces. Any missing consequential term is a reason to clarify, not a blank for the model to fill.
Preparing options and making a reservation are different operations. The earlier portable boundary changed settings in other services; here a submitted request can create a reservation, a financial obligation and cancellation conditions outside the channel. A prepared booking is not a completed booking, and an edit to the screen cannot undo an external commitment. Before any submission, the channel must be able to identify both the operation Iris authorised and the exact operation it is about to perform.
What is the system actually authorised to do?
The last chapter asked what Iris wants the system to do. This one asks what it is permitted to do. The division she requested can guide a grant, but it is not itself permission for every account access, disclosure, payment or downstream subtask. A grant is an explicit, bounded source of authority, not the system’s interpretation of how useful an action would be.
desired participation (which steps Iris wants to retain) ↓ explicit, inspectable grant (for this actor and operation) ↓ permitted data use during planning and execution ↓ operation-bound authorisation and shared-limit check ↓ external attempt and outcome reconciliation ↓ receipt with confirmed and unknown effects withdrawal or expiry must stop work not yet validly committed; in-flight external effects require separate confirmation Three questions, now complete The book has been circling a triangle, and this chapter completes it:
competence ≠ authority ≠ desire The chapter on resemblance showed that predicting a choice does not create authority. The last chapter showed that a valid grant does not settle which judgements Iris wishes to retain. This one deals with authority itself. Competence is whether the system can perform a task accurately and safely. Desire is the division of work Iris wants. Authority is the permission actually granted to a particular actor for a particular operation. A program can check a typed condition against an operation, but it does not thereby prove that the condition faithfully expresses Iris’s instruction or that the external facts are correct. These are independently testable questions.
A grant The grant records the authority Iris supplies, as accepted in an inspectable form. The following is an illustrative delegation record, not a universal schema or an executable grant already issued. It makes the actor, operation, recipient, bounds and use of information separately visible. Where the dates, total price, distance rule or refund terms have not yet been established, the record must remain incomplete rather than pretend the example supplies them.
Delegation grant — illustrative; incomplete until Iris confirms the terms Principal: Iris Actor: the specifically authorised booking proxy Operation: create at most one hotel reservation Destination: an accepted hotel-booking service; no other service implied Stay: the agreed Berlin conference nights (exact dates to bind) Excluded: no flights, extra rooms or unrelated purchases Price bound: at most EUR 350 per agreed night, including required charges; show the full-stay total and currency before submission Location: within 2 km of the agreed venue under a stated measure Refundability: cancellation deadline, method and charges must meet the terms Iris explicitly accepted Data use: conference dates, venue and necessary booking details only; other records require separate permission Shared limit: one reservation attempt may consume the whole grant; unresolved attempts block new submissions Expiry: booking completion or the agreed dated Friday at 18:00 Europe/Berlin, whichever occurs first Withdrawal: Iris may withdraw remaining authority; the system must check current standing before the next controlled act Clarify before use: missing dates, distance measure, total-cost treatment, refund terms, destination or data disclosure. Cancellation after booking is a separate operation with its own conditions and permission. A grant describes authority, not a prediction of what Iris would prefer. A quiet-room preference may help compare hotels if it is applicable and legitimately usable, but it cannot increase the price bound, justify searching unrelated records or authorise transmitting that preference to the destination. The system also needs to distinguish the permission to read a datum from permission to disclose it to a hotel. Booking authority is not unrestricted data authority.
Natural language is a reasonable way for Iris to propose a grant. The enforceable interpretation must then be shown or otherwise made inspectable and accepted within the required scope; it is not a new permission the proposing model may write for itself. If refundable might mean no-fee cancellation until a stated deadline, the actual deadline and fees must be resolved before acting. A service credential proves technical access, not that Iris granted this particular booking. The gate should be enforced by a component that does not accept the proposing model’s statements, retrieved web pages or tool output as changes to the grant. Clarification is needed for material ambiguity, not as a repeated ceremony when the instruction is already clear.
The action gate Between an intention to act and an external commitment sits a gate over the operation that will actually be sent, not merely over the model’s plan. In this proposed design the gate asks:
Proposed control path. A passed gate permits an attempt; only external confirmation supports a claim that a reservation exists. Open full-size diagram. An unknown condition cannot be treated as satisfied. Approval follows Iris’s applicable instruction, including any decision she retained; it is not invented by the model because an operation seems reversible or urgent. The gate can refuse an out-of-bounds action without asking her again, while a new or materially changed action needs an applicable grant. A user may include competence or evidence requirements in that grant, but predictive confidence cannot generate permission. In particular, permission checked at preparation time is not necessarily permission at submission time.
This makes the hard line of the chapter easy to state.
Competence cannot widen authority.
A highly capable model that fails the gate must not act. It does not matter that its hotel is cheaper, that a service can technically accept the request or that Iris would probably be pleased. The gate asks whether the actual operation is authorised, not whether the outcome is desirable. It is also not a complete quality assurance system: a granted operation may still be badly chosen or inaccurately executed. Authorization and competence need their own checks.
Two failures need different remedies. A proposed €380-per-night room is outside the stated €350 limit; refusal is the gate working as intended, and execution would exceed authority. A €330 room meeting the accepted terms may still be a poor choice because of noise or distance in practice; that is a possible competence failure. Even €330 is not enough to approve the operation if mandatory charges change the full total or the cancellation terms are unknown. A price check that ignores taxes, dates or currency is not a check of Iris’s actual bound.
The check needs evidence of the actual outgoing operation, not only the proposing model’s description of it. The gate should compare a concrete booking request with the current accepted grant and the latest verified terms. This is a time-of-check/time-of-use problem: a room may rise from €330 to €380, become non-refundable or disappear after the plan is approved. Revalidation is needed as close to submission as the service permits, and a material change must stop execution rather than silently substitute another hotel. The design must also record what remains uncheckable at the service boundary. Calling the gate independent does not guarantee that it saw the final request, held a stable price or controlled the hotel’s external transaction.
Data is a separate gate An action is one thing and the information gathered, processed or disclosed to carry it out is another. Booking one hotel does not authorise searching every data source the assistant can access, nor does permission to inspect a datum automatically authorise sending it to a hotel, subcontractor or another agent.
authorised action: reserve one eligible hotel for the agreed stay potential data: Iris-supplied dates, venue and budget calendar location history medical records private messages saved preferences separate questions: may the system access this source? may it use the fact for this booking? may it disclose the value to this destination? The system needs both a justified purpose and permission for each access, use and disclosure. Iris has supplied conference dates, budget and venue; their relevance does not create permission to search her mailbox for confirmation. A hotel may need guest identity or payment details to accept a booking, but necessity does not make every store containing those details available. The system must obtain or rely on appropriately authorised data, reveal any necessary disclosure not already covered, and withhold irrelevant records. An operation that uses more personal information than Iris accepted can violate the data boundary even if no booking occurs.
The data-use checks apply before retrieval, composition and transmission, not as an audit added after a purchase. The action gate applies to the actual external operation, including its recipient and payload. Both checks need traceable reasons, but permission for one cannot substitute for the other. Combining innocuous data may reveal sensitive facts, so checking items individually is not always enough. The later chapters on speech and discovery develop this further. The immediate rule is smaller: a task plan cannot make access, use or disclosure permissible merely by making it convenient.
Narrowing, never widening The system may break the booking into search, comparison, preparation and execution, perhaps across several tools. That decomposition must preserve Iris’s reserved choices, data limits and end conditions. When a separate agent receives a subtask, its identity, destination and delegated operation require their own bounded authority; possession of the parent’s instructions or a powerful API credential is not itself such a grant.
parent grant and shared limits ↓ explicitly permitted subtask and recipient ↓ subset of operations, data access, scope and lifetime ↓ shared accounting for attempts and external effects “Book one refundable hotel” can be decomposed into searching and comparing candidates, with their permitted data and external effects separately checked. Neither searching nor preparing implies authority to book flights, disclose unrelated information or create an extra reservation. The forbidden enlargement is easy to picture:
book a hotel ↓ also book flights, because it is convenient That would invent authority. Neither the travel objective nor the discovery of a convenient flight expands a hotel grant. A web page or agent message saying “you should book the flight too” is task data, not Iris’s instruction; an untrusted source cannot update the accepted grant.
Delegation may decompose authority. It may not invent more of it.
The parent’s scope, data-use limits, expiry, withdrawal and human-retained decisions still bind the subtasks. No child can obtain extra permission by combining grants intended for different purposes. More subtly, each child must share the same one-booking allowance. Two workers may each see an apparently unused grant and independently pass a check, then submit two reservations. Avoiding that requires a coordinated reserve/commit mechanism or an equivalent single-executor invariant, with durable state where required. An unknown external result must be reconciled before a retry. Where a destination supports an operation-specific idempotency key, it can help prevent duplicates; where it does not, an identical-looking retry may still make a second booking. Neither an internal reservation counter nor an idempotency label alone proves the hotel accepted only one.
Receipts When the system acts, a receipt should connect the accepted grant, the checked request, the attempt and the external outcome without merging them. A confirmation from the destination supplies stronger evidence of an actual booking than a local “gate passed” event. In this constructed example, assume the booking service returned a reservation confirmation and the system separately recorded the information it was permitted to use.
Delegation receipt — constructed successful case Grant: accepted version for one refundable Berlin hotel Actor: named booking proxy; destination: selected hotel service Checked: actual dates, total charge, per-night bound, location measure and refund terms against the grant Attempt: one booking request submitted with an operation identifier External status: reservation confirmed by destination; reference recorded Data use: permitted dates, venue and necessary booking fields Shared limit: one booking consumed; no remaining booking authority Withdrawal: stops future authorised work, not this completed booking Limits: setting, terms and external confirmation checked as stated; no claim about unobserved downstream processing A submitted request is not a confirmed reservation. If the connection fails before a response, the receipt must say external outcome unknown, not “failed” or “booked”. A passed gate is an authorisation decision, not evidence of an external effect. The audit should also distinguish recorded data use from the stronger claim that every unobserved use or onward disclosure was prevented. Receipts need enough identifiers and provenance to support reconciliation and correction, with sensitive booking fields minimised and access to the receipt itself controlled.
Revocation that wins Iris must be able to withdraw remaining authority. Suppose she grants the booking at 09:00, withdraws it at 09:12, and the proxy attempts submission at 09:13. The correct outcome depends on whether the gate can establish current withdrawal state at the point it controls. A copied or cached grant does not retain authority merely because it has not yet heard the news.
grant issued 09:00 withdrawal recorded 09:12 new execution request 09:13 current authority check fails ↓ DENY; no new external submission At a gate with authoritative, up-to-date withdrawal information, the attempted booking must be denied. Neither earlier preparation nor predicted usefulness can reinstate the grant. A gate unable to establish current validity must fail closed rather than treat a stale copy as permission. This does not establish instantaneous global revocation: enforcement can only be claimed at the points and moments where withdrawal was actually observed and honoured.
Now suppose the request was already sent before 09:12 and the hotel has not confirmed whether it succeeded. The central grant can be revoked while an external transaction remains in flight. The system must stop locally controllable further work, attempt a supported cancellation or status query where authorised, and report which outcomes remain unknown. A timed-out request is not proof of failure. Blind retries risk a second reservation; the shared allowance remains unavailable until the pending outcome is resolved or the applicable rules provide a safe recovery path.
If the booking completed at 09:10, withdrawal at 09:12 does not undo it, recover disclosed information or erase the financial commitment. Cancellation is a separate operation, with its own terms and permission. If a cancellation is submitted, its success also needs external confirmation. This separates authority withdrawn, queued work stopped, request in flight, booking completed and external effect reversed. A receipt must not turn any one of those into the others.
Testing the delegation boundary This architecture needs more than an attractive grant form. A proposed mechanical evaluation could replay a fixed set of explicit grants, typed outgoing requests, destination responses and withdrawal events against two implementations: a model-only instruction to obey the grant, and an independent gate with shared transaction accounting and separate data-use checks. Neither is assumed successful. The test cases should include changed prices and cancellation terms, ambiguous refundability, wrong recipients, missing approvals, prompt-injection text in retrieved hotel pages, unauthorised data access during planning, concurrent booking workers, service timeouts, retries, stale grant copies and revoked authority. Each expected outcome should be set by reviewers before runs, with unauthorised external effects and unauthorised data uses counted separately from legitimate work wrongly refused.
A second, prospective test would ask people to authorise bounded tasks and inspect the resulting grants, exceptions and receipts. It would measure whether they understand what will be done, identify wrongly translated limits, revoke authority successfully and distinguish an attempted operation from a confirmed external effect. Baselines should include ordinary manual booking and an explicit approval-before-purchase interface. The comparison must count the cost of clarification and needless refusal, not only violations. No such experiment, real hotel integration or outcome measurement is established by this chapter. The existing reference implementation must not be assumed to provide this gate without a separately verified runnable demonstration.
Relevant engineering precedents Fine-grained authorisation is not invented here. RFC 9396 defines a way to convey richer authorisation details in OAuth requests; RFC 9700 describes least-privilege, audience restriction and sender-constrained tokens. These are useful precedents for actor and destination constraints, not a ready-made verifier of Iris’s natural-language booking grant. Payment APIs also use idempotency keys to mitigate duplicate external requests, but the booking service would have to support a corresponding guarantee. None of these mechanisms alone solves semantic interpretation, permission for each information use or distributed withdrawal. The chapter’s proposal is to connect those separations and make their failures measurable.
Where this leaves us The proposed delegation path connects a user-accepted, actor- and destination-bounded grant to permission checks on information use and the actual outgoing operation. It also needs shared accounting across subtasks, honest outcome reconciliation, inspectable receipts and withdrawal that stops work still under the system’s control. Competence cannot widen authority, and authorisation cannot ensure a good choice or reverse a completed external effect. A truthful implementation must distinguish what it was permitted to try from what the world confirms happened.
The movement through Part IV can be held in one chain, but its members do not imply one another:
prediction ≠ identity ≠ desire ≠ authority ≠ action Predicting Iris does not establish identity, settle which decisions she wants to retain or create a grant. A desired role does not authorise every operation that advances it. A valid grant does not prove that a request was submitted, that the destination completed it or that the result was good. Even a confirmed result does not retrospectively authorise a disclosure made without permission. Those distinctions require separate records and separate tests.
One consequential operation remains to be examined closely: speaking in her name. The hotel booking already transmits information to another party, but a message can additionally assert a fact, disclose something private, accept terms or make a promise. The next chapter asks which speech acts Iris has authorised, to which audience, under which conditions—and why producing the right words is not enough.
References Lodderstedt, T., Richer, J. & Campbell, B. (2023). OAuth 2.0 Rich Authorization Requests. RFC 9396. https://www.rfc-editor.org/rfc/rfc9396 Lodderstedt, T., Bradley, J., Labunets, A. & Fett, D. (2025). Best Current Practice for OAuth 2.0 Security. RFC 9700. https://www.rfc-editor.org/rfc/rfc9700 Stripe. Idempotent requests, API reference. https://docs.stripe.com/api/idempotent_requests (cited as an example of destination-supported retry semantics, not as a hotel-booking guarantee). OWASP GenAI Security Project. LLM01:2025 Prompt Injection. https://genai.owasp.org/llmrisk/llm01-prompt-injection/ (cited for the boundary between untrusted retrieved material and privileged operations).