Boundaries make the agent trustworthy.

Hello from Corduroy Labs.

We spent this week doing something that rarely shows up in a software demo: we took privileges away from our own agent.

When you first stand up an agentic workflow, the temptation is to hand the system access to everything. It feels powerful to watch a single process read a database, rewrite a file, and restart a service all at once. The friction disappears.

But power without boundaries is a liability sitting quietly in the corner. If an agent can change anything, you can never quite trust what it does.

So we spent the time. We narrowed what the agent can touch. We wrote the rules down. We made it document its work. We taught it to verify reality, not just configuration. And we gave it some real context about the person it is working for.

It was quiet, careful work. Most of it will never be visible to anyone except us. That is the point.

Narrow what the agent can touch

Agents do not need root access. They do not need the ability to silently rewrite the canonical state of a system.

Our agent now runs as a non-root user. It can read the terrain, but it cannot directly alter the core files that keep the studio online. When it needs to document a change, it does not write to the live source. It queues a markdown entry. A separate, tightly scoped process drains that queue and writes the canonical record.

We took the same approach with the database. Instead of a model where the agent could in theory run any query, we narrowed it to a single read-only backup command. Everything else requires a human in the loop.

This is what we mean when we say work needs an address. Permissions are part of that address. By narrowing what the agent can do, we raise our confidence in what it actually does.

Write the rules down

We also codified the rules of engagement. Every scheduled job the agent runs now passes through five explicit policies.

Before any work starts, it reads the ground truth: a small set of documents that describe the current state of the studio, the operating policy itself, and the recent history of changes. It hashes them so we can tell if they have drifted. It will not start a job without them.

Every change it makes is documented in the changelog on the same run. Every state change comes with a backup, taken before, and a rollback bundle, prepared after. Software updates are surfaced as recommendations and never installed automatically. And after any change, the agent confirms that the affected systems are still actually working.

These are not suggestions inside a prompt. They are structural guardrails inside the operating layer. The agent cannot decide to skip them, because they are not its decision to make.

Human review by design means the agent prepares the work, classifies it, summarizes it, and proposes the next step. People still own the judgment, the commitments, and anything that goes to the outside world.

Verify the terrain, not the map

Configuration files drift. A port might be configured to listen, and not actually be listening. A hostname might be defined locally and have no public DNS record. Environment variables get renamed in one place and not in another.

When we built a functional health check for the agent to run, it immediately found three of those misalignments that had been sitting quietly in the background. A mail port was not listening. A hostname was not publicly routed. Two environment variables were named in the agent's code one way and in the actual environment file another way.

The configuration map said everything was fine. The terrain said otherwise.

That is the kind of work we want agents doing on our behalf. Not generating more configuration. Surfacing the gap between the configuration and reality, so the operator can decide what to do about it.

Give the agent some context

Agents work better when they understand the person on the other end of the work.

We assembled a profile of the operator the agent works for. Not a list of abstract preferences. A concrete summary built from our own public sites: the studio's operating thesis, six hundred-odd personal journal entries spanning two decades, communication preferences observable from the writing itself.

The agent loads it at every preflight. It now has a sense of where the work happens, who is involved, and how we like to communicate. The default register softens. The voice settles down. The output stops sounding like a press release and starts sounding like a colleague who knows the room.

None of this is mystical. It is just context, applied early enough to shape the work rather than late enough to require rewriting it.

Open where it matters

We self-host the mail server, the CRM, the chat, the documents, and the agent runtime. That is not a cost decision. It is a clarity decision.

Boundaries are clearer when the file paths are ours. The logs are clearer when the format is ours. The state is clearer when the database is ours. If we want an agent to read an inbox or update a customer record, we can design the path it takes, observe what it does on that path, and remove the path if we change our minds.

Open source where it matters is not a slogan about cost or ideology. It is a working condition. It is what makes the rest of this possible.

A foundation you can trust

You cannot prompt your way to reliability.

You build the infrastructure that makes the agent safe to use. You narrow what it can touch. You write the rules down. You make it document its work. You teach it to verify reality. You give it real context about the operator it works for. Most of that is undramatic engineering.

That is what we are doing here in the studio. We are building the foundations for agentic work, starting with our own systems, so we can help others build theirs next.

It feels like progress.

Cheers,
Corduroy Labs
Truckee, California