The agent I shut down last week is coming back online.

This time, it’s being treated like a member of staff.

The response to my previous post was overwhelming. Hundreds of messages. Engineers, founders, executives, journalists. Almost everyone asked a version of the same question:

How do I experiment with autonomous AI without exposing everything?

In that post, I wrote about shutting down an autonomous AI agent that many people referred to as ClawdBot. The system has since been renamed Molt. For simplicity, I’ll refer to it here as the agent.

The name matters less than the shift in how it now operates.

We’re using the wrong mental model

I think most people are making the same mistake, for a very understandable reason.

For decades, we’ve been trained to think about software in a specific way.

Software is passive.
Software has no agency.
Software only does things when we click.

So if we want it to be useful, we plug it into our world.

That’s the SaaS pattern.

You install a tool, then you connect it.

Sign in with Google.
Connect your inbox.
Grant calendar permissions.
Link Slack.
Give it access to Drive.

That logic has made sense for a long time.

Traditional software is useless without access because it cannot reason, initiate, or operate independently.

AI agents are not like that.

They are useful before they touch your identity.

They can reason.
They can plan.
They can execute.
They can communicate.
They can coordinate.

So when people instinctively give agents access to their email, calendar, files, and tools, they’re not being reckless. They’re applying a tool-era reflex to an agent-era system.

That’s the category error.

With agents, the right question is no longer “what does it need access to?”
It’s “what should I delegate, and what should remain mine?”

The hidden problem I didn’t fully appreciate at first

There was another issue that only became obvious once the agent was live.

Because it was operating inside my own systems, using my email, my files, and my tools, something subtle but unsettling started to happen.

I was no longer always sure what I had done versus what the agent had done.

Emails appeared in my sent folder.
Files were created in my workspace.
Changes happened inside systems I normally control.

Nothing was technically wrong. But psychologically, something was off.

Agency had blurred.

When an agent acts inside your identity, you don’t just delegate work. You collapse authorship. You lose the clear mental boundary that lets you say: this was my decision, this was theirs.

That matters more than I realised.

Without that separation, accountability becomes fuzzy. Trust becomes harder to build. Even confidence in your own actions starts to wobble.

That was a big part of why I shut it down.

The answer isn’t less power. It’s separation.

The instinctive response is to strip capability away. Lock things down. Reduce autonomy.

That misses the point.

Instead, I changed the frame entirely.

I stopped treating the agent like software and started treating it like what it actually is.

A new member of staff.

That shift solved two problems at once.

It reduced risk.
And it restored clarity.

The employee model

Here’s the architecture I’m now running.

A dedicated machine. A separate Mac mini. No shared devices. No shared user accounts. A physical power switch that shuts the whole thing down.

A separate identity. A dedicated email address. A dedicated phone number via eSIM. Its own WhatsApp and Telegram accounts. Its own Apple ID. Its own password manager vault.

A closed instruction surface. The agent does not listen to the world. Its email only accepts messages from me. Its messaging channels only respond to my accounts.

Information by delegation. It does not have my inbox. I forward what I want it to handle. It does not see my full calendar. I share a limited availability calendar.

An isolated build environment. Its own GitHub. Its own cloud accounts. Its own API keys.

Why this works on a human level

Now, the boundary is obvious.

I know what I’ve done.
I know what the agent has done.

There’s a clean trail. Clear authorship. Clear responsibility.

The agent’s actions feel like delegated work, not mysterious self-action.

That psychological separation is just as important as the technical one.

It makes supervision possible.
It makes trust incremental.
It makes autonomy tolerable.

The air gap principle

This creates a real air gap between the agent’s operational world and my personal and professional identity.

The system remains powerful.
The system remains autonomous.
The system remains fallible.

But failure becomes observable, recoverable, and contained.

Forensics are clean.
Recovery is fast.
Trust can be built over time.

If you want to experiment, start here

If you take nothing else from this, take this:

Do not integrate an agent into your identity.
Stand it up beside you.

A few principles if you’re experimenting:

Do not start with your primary identity.
Do not give ambient access.
Do not assume intent equals correctness.
Do not confuse convenience with safety.

Think in terms of delegation, not integration.

The underlying principle

We don’t restrict employee access because we don’t trust people.

We do it because separation of concerns is basic operational hygiene.

The same logic applies to AI agents.

If you wouldn’t give a new hire that level of access on day one, don’t give it to your AI.

I’ll share more as this evolves. What works. What breaks. And where this model still falls short.

Craig Hepburn is an AI strategist and builder, Perplexity Fellow working at the intersection of technology, psychology, and system design to shape how AI operates responsibly in the real world.