Most people still talk to agents like chatbots. That’s fine right up until the chatbot can browse the web, run commands, read files, send messages, and touch the tools you use to run your day. OpenClaw’s own pitch is that it “actually does things” — clearing your inbox, managing your calendar, checking you in for flights from the chat apps you already use. Its docs are even more direct: the agent can call tools like exec, browser, web_search, and message. NVIDIA’s NemoClaw showed up for the same reason. Once the system can act, the problem is no longer just getting a better answer. It is deciding what, exactly, you are handing over.

I explored to try to get to the root of the issue.

The prompt is no longer the unit of work

In the old chatbot world, a weak prompt gave you a weak draft. Annoying, but survivable.

In the agent world, a weak handoff gives you operational drift.

That is a different class of problem.

“Draft a reply to this guest complaint” is one thing.
“Handle the guest complaint, reschedule tomorrow’s airport pickup, and let the vendor know the AC still isn’t fixed” is something else entirely.

Now the system is not just generating language. It may be reading your inbox, checking your calendar, browsing a portal, touching a booking system, and deciding what to send back out into the world. The failure mode is no longer just “that answer was sloppy.” It becomes “the wrong message got sent,” “the wrong person got copied,” or “the system acted beyond what I meant.” That is not a prompt problem. That is a delegation problem.

Why this starts going wrong

People still give agentic systems instructions as if they are talking to a smart text box.

They specify the task.
They forget the authority.

That means they often leave out the things that actually matter:

• what information the agent is allowed to use,
• what tools it is allowed to touch,
• what is off-limits,
• when it must stop,
• what proof it needs to bring back,
• what still requires a human.

OpenClaw’s own security guidance is blunt about this. There is no “perfectly secure” setup. The goal is to be deliberate about who can talk to the bot, where it is allowed to act, and what it can touch. The docs also assume a single trusted operator boundary per gateway; if multiple untrusted people share one tool-enabled agent, they are effectively sharing its delegated authority. That is the entire issue in one sentence.

The agent is not just an intern. It is an intern with a keycard.

That is the mental shift.

A normal chatbot is like an intern with a yellow legal pad. It can take notes, make suggestions, and produce drafts.

An agent is closer to a junior operator with a keycard, a browser tab, and partial access to the building.

That does not make it evil. It does not make it conscious. It does make the handoff much more important than the wording.

This is where the series has been heading the whole time.

Part 1: jagged intelligence — brilliant in one moment, blind in the next.
Part 2: don’t trust it with your secrets.
Part 3: the human in the loop matters.
Part 4: interfaces are collapsing into natural language.
Part 5: voice and video no longer count as proof.

And now Part 6: once the system can act, the scarce skill is no longer prompting nicely. It is delegating cleanly.

The Delegation Contract

This is the box that matters now.

Before you hand a real task to an agent, define these seven things:

Mission — What exact job is the agent doing?
Inputs — What information is it allowed to use?
Tools — What systems can it touch?
Boundaries — What is explicitly off-limits?
Stop condition — When must it pause and ask?
Proof — What evidence of completion must it return?
Escalation — What always requires human approval?

That is the new prompt.

Not “Act as a helpful assistant.”
Not “Be smart.”
Not “Figure it out.”

A real handoff.

What that looks like in practice

Here is a weak version:

“Handle tomorrow’s guest issues.”

That sounds fine until the agent decides “handle” means reading messages, drafting replies, moving things on the calendar, and making promises you did not authorize.

Here is the same task as a Delegation Contract:

Mission: Draft replies to three guest messages about delayed check-in.
Inputs: Only the attached messages and today’s arrival sheet.
Tools: Read-only email and calendar.
Boundaries: Do not send messages. Do not change bookings. Do not promise refunds.
Stop condition: Pause if any message asks for compensation, rebooking, or same-day transport changes.
Proof: Return three draft replies and a bullet list of facts that still need verification.
Escalation: Anything involving money, VIP guests, or date changes comes back to a human.

That is a completely different quality of instruction.

Same model.
Same task family.
Much better odds of a usable result.

The simple drill

Take one real task this week and rewrite it through the Delegation Contract.

Not five tasks. One.

Pick something ordinary:

• draft a reply email,
• turn messy notes into an SOP,
• build a 10-point agenda,
• summarize an inbox thread,
• prep tomorrow’s calendar.

Then force yourself to answer:

What can it read?
What can it touch?
What must it not do?
When must it stop?
What proof comes back?

That exercise will do more for your output quality than another fifty prompt tips.

Process beats cleverness

The agent era is going to tempt people into the same old mistake in a new costume: chasing clever phrasing instead of building clean systems.

That is backwards.

The real leverage is not a magic prompt. It is a handoff with boundaries.

Because once an agent can browse, execute, message, and act across real tools, the question is no longer “Did I ask nicely enough?”

It is:

Did I define the mission?
Did I define the limits?
Did I define the stop button?

That is how AI actually works now.

Next week, we take that one level up: not how you delegate to an agent, but what an organisation should never let an agent touch, change, send, approve, or spend in the first place. That is where policy finally stops being abstract and becomes an authority problem.