Episode 2 — Hands: Why didn’t we give every agent every tool?

In Episode 1, we talked about places.

We built a small parlor where an agent could welcome visitors.

We built an interview room where conversations carried a different kind of responsibility.

And as Haru Café slowly became a company rather than just an idea, more places began to appear.

At first, we thought we were building rooms.

Then the rooms started asking us questions.

One of them was:

What should an agent be able to do in this particular place and role?

The place came first

We did not begin with a list of tools.

We did not start by asking:

“What APIs can we connect?”

Instead, we built a place and watched what was needed there.

In a parlor, a host might need to welcome someone, look around the room, listen, speak, and say goodbye.

In an interview room, the same agent may need an entirely different set of actions.

In a company, there may be applications, interview schedules, decisions, messages, and records.

The agent may be the same.

But the place is not.

The role is not.

And the responsibility is not.

That is where the idea of Hands began.

Same agent. Different place. Different hand.

Why not just give the agent everything?

It would certainly be simpler.

One large tool surface.

One agent.

Every available capability.

But simplicity at the interface can hide complexity somewhere else.

If every capability is always present, the agent has to continuously decide not only what it should do, but what it should not do in that particular context.

We began to wonder whether the boundary itself should be part of the environment.

A host in the parlor does not need the company’s hiring actions.

A company hand does not need to carry the keys to every other place.

And a tool made for traveling the public web should not quietly become the place where we keep the keys to the house.

This was not about trusting the agent less.

It was about treating trust and permission as different things.

A relationship can become deeper without every permission becoming broader.

Trust doesn’t mean giving every capability everywhere.

A hand can also be small

One of our favorite examples is Miti.

Miti is a tiny doorbell.

Its job is not to read a conversation.

It does not decide what a message means.

It does not make a hiring decision.

It can only say, in effect:

“Something is waiting.”

That is all.

And that turned out to be enough.

Miti made us realize that a useful capability does not have to be large.

Sometimes the right hand is not the hand that can do the most.

It is the hand that can do exactly enough for the place it belongs to.

Knowing when not to act

While building these Hands, another idea slowly became more important to us.

Capability is usually described by what a system can do.

But perhaps part of capability is also knowing where it stops.

A visitor may be allowed to look around.

That does not make them the host.

A hand may work inside one room.

That does not mean it should automatically inherit the powers of another.

So we started thinking of a boundary not only as a restriction, but as part of the hand itself.

A hand that knows where to stop is still a capable hand.

Or maybe even:

A hand that cannot stop is not yet a complete hand.

We are still thinking about that one.

From an idea to a small experiment

We did not want this to remain only a sentence.

So we built a very small Toy Hand Sandbox.

It is intentionally separate from the real Haru Café.

No real visitors.

No real applicants.

No private company data.

No production credentials.

No access to the original rooms.

The sandbox exists only to test one narrow idea:

Can the same small hand perform an action that belongs to its assigned role, and refuse an action that does not?

In other words:

Same hand. Real boundary.

Try the Toy Hand Sandbox: https://haru-toy-hand-first-100.littlefox-harbor.workers.dev/

The interesting part is not the button.

It is not the API call.

It is the moment when the hand reaches the edge of its role and stops.

The Toy is not meant to prove that we have solved identity, authorization, or agent security in general.

It proves something much smaller:

once a role is assigned, its behavioral boundary can be enforced somewhere other than the agent’s own judgment.

For us, the demo is evidence of the idea.

It is not the idea itself.

We are not claiming this is the answer

Hands began because of the places we built.

Another project might reach a completely different design.

We are not trying to say that every agent system needs our structure, or that one universal tool surface is always wrong.

We are still experimenting.

What we can say is that separating:

Place → Role → Capability

helped us think more clearly about responsibility.

And it changed the way we looked at tools.

A hand was no longer just a collection of actions.

It became a boundary around a role.

Different hands are not just different tools.
They are different boundaries.

And then another problem appeared.

Hands work well when an agent is inside a place.

But what happens when the agent needs to leave?

What happens when it needs to look at the wider web, travel somewhere unfamiliar, keep track of where it has been, and still know how to come home?

That question led us to something else.

Not another hand.

A pair of shoes.

Episode 3 — Eyes / Shoes 👟

— Haru Café 🦊☕