Give an Agent an Inch

I’ve written thin tickets my whole career. A sentence or two about the outcome, maybe a link, and then: go build it, ask me questions as you get into it. I’ve had people look at one of my tickets and ask where the rest of it was. There is no rest of it. I don’t over-optimize a ticket, because the more you specify, the more of the developer’s creativity you take away.

That habit works with people for a reason I never had to think about until recently. A good engineer knows what they don’t know. When the ticket runs out, they ask.

An agent doesn’t ask. It fills.

Picture the button a lot of ticket trackers are starting to add: hand this ticket to an agent. On one side, the requirements. On the other, the code repo. Good luck. The first time I saw one, I made the obvious joke about engineers taking the rest of the year off. Then it got a little scary, because I could see exactly where it was going. My next thought wasn’t about what it could build. It was about who should be allowed to press it.

That reaction is the argument. When the thing doing the work stops asking questions, the PM’s job moves. Describing the outcome isn’t enough anymore. You also have to decide how much the agent may do before it checks with a human, what it has to tell you afterward, and who can stop it. Most PMs have never had to set anyone’s authority. They’re about to set it for dozens of things that never raise their hand, and that decision is quickly becoming the real spec.

You give it an inch, it takes a foot

The way I describe agents to people is this: give them an inch and they take two. Give them six inches and they take a foot. Not because they’re scheming. An agent is built to finish the task, and anything you didn’t rule out looks like part of the task.

You’ve probably seen the small version already. Point an automated tester at a product and ask it to find problems. It will. It will also file every one of them as a ticket, and now somebody has to figure out which bugs are real before anyone can work on any of them. Nobody told it to create tickets. Nobody told it not to.

Here’s a quieter one. Ask people building side projects with coding agents what database their project runs on, and a surprising number of them don’t know. The agent picked it. Some of them go ask the agent, which is a strange position to be in with your own project. No one granted the agent the authority to make an architecture decision. No one withheld it either, so it made one.

And the big version is what security people keep running into. Agents turn up in a lot of places nobody remembers putting them, sometimes reaching things they shouldn’t. Each one was set up by someone who meant well and clicked through a permission screen to get on with their day.

The gap between what you asked for and what the agent did isn’t really a bug in the agent. It’s authority nobody wrote down. With people, judgment and culture fill that gap. A new hire knows not to drop a production table even if no ticket mentioned it, and if they aren’t sure, they ask. An agent has no culture to fall back on. It has the instructions you gave it and the access you granted, and it will use all of both.

That’s why the thin ticket, which I’d still defend for people, is a liability with agents. It isn’t that agents need more detail about the outcome. Often they need less. They need far more detail about the edges.

Access is a switch. Authority is a ladder.

Most of the conversation about agent safety has been about access: which systems it can reach, which scopes the token has. That matters, but it’s the wrong unit for a PM. Access says what the agent can touch. Authority says what it may do with that thing without asking first.

Logistics Reply, a supply-chain software company, recently published an authority model for agents that runs as a ladder, from inform and recommend at the bottom up through act, coordinate with other agents, and finally governed autonomy. The levels themselves are useful, but one line in their framing is better: “the ability to act does not, on its own, justify permission to do so.” I’d put that sentence at the top of every PRD template that touches an agent.

You don’t need their exact rungs. For most product work, four will do. Tell me what you found. Suggest what to do and wait for a yes. Do it and tell me. Just do it. Every task you hand an agent should sit on one of those rungs, on purpose, and the rung should be written in the spec next to the outcome.

Run the earlier examples through that and they get easy. The automated tester belonged on “suggest”: list the bugs, let a human decide which become tickets. The button that turns a ticket into code might reasonably be “do it and tell me” on a branch, and almost never “just do it” anywhere near production. The database choice should have been “suggest,” because it’s a decision someone will live with for years.

I’ve been using AI a lot as a delegator. Anything tactical and repeatable, I’ve been offloading as much as I feel comfortable with, and it’s freed up my brain in a way I didn’t expect. But look at the limit in that sentence. “As much as I feel comfortable with” is an authority level. I just never wrote it down, which means it lives in my head and nowhere the agent can see it.

Some people are already building ladders by hand. I know people who won’t let their always-on agent anywhere near their email. Instead, the agent asks a second model that has read-only access, that model searches and reports back, and nothing in the chain can send anything. It’s clunky, and it’s also exactly the right instinct: one agent may ask, another may read, nothing may act. You also see people set authority by who’s behind the agent. Plenty of users will grant read access to an assistant from a big, well-funded company and refuse the same request from a small startup they found last week. Your users are making these calls about your product whether or not you designed for them.

There’s a real tension here, and I don’t think it’s solved. Every approval step adds friction, and the entire pitch of agents is less friction. Put everything on “suggest” and you’ve built a slower intern. I’d still start low and move a task up the ladder once it has earned it, the way a decent manager gives a new hire more latitude after a few months. That’s slower than turning everything on at once. It’s a lot faster than cleaning up after something you never meant to allow.

Make the agent hand you a receipt

Here’s a thought experiment I keep coming back to. What if the companies running personal agents, Muse or Anthropic or whoever, were required to send you a report of everything the agent accessed on your behalf? A statement, like the one your bank sends. What it opened, what it changed, what it sent, and why.

Nobody requires that today. But you don’t need a regulation to build it into your own product. If your feature lets an agent act for a user, the user should be able to see what it touched. That’s the second half of authority. The ladder decides what the agent may do; the receipt is how anyone finds out what it actually did.

Then there’s the stop. Plenty of security vendors are now building kill switches for agents, and the smarter ones put the switch outside the environment the agent runs in, because detection and containment aren’t the same thing. Dataiku’s CEO put it well: “An agent you can spot in one system but can’t stop everywhere else isn’t contained — it’s just been noticed.” If the only way to stop your agent is to ask the agent, you don’t have a stop.

The market sees all of this. Identity companies, security startups and chipmakers are all shipping some version of agent controls, and a group including Meta, Walmart, Shopify and Sierra is working on a shared protocol for how agents talk to websites. It’s the Bluetooth move: lots of devices, one agreed way to connect. That’s a sign the plumbing will get better. It won’t decide, for your product, what an agent should be allowed to do. A protocol can carry the permission. Someone still has to set it.

You’ll also be on both ends of this. As agents start showing up at your product on behalf of users, you’ll be the one deciding what an outside agent may do inside it. The same ladder applies. Can it read prices? Fill a form? Complete a purchase? Each of those is a rung, and right now most products answer all of them by accident.

Influence without authority, flipped

For as long as I’ve been in product, the job description has included some version of “influence without authority.” You don’t manage the engineers or the designers. You persuade, you align, you write the doc that gets everyone moving.

That’s flipping. PMs now hand out authority constantly, mostly by clicking yes on an install screen or checking a box on a token. Most of us never managed anyone formally, so we never built the habit good managers have: deciding, task by task, how much latitude someone has earned and what they owe you in return.

Agents need that habit more than people ever did, because people push back and agents don’t. The engineer who gets a thin ticket asks what you meant. The agent that gets a thin ticket decides.

So the next time you write a spec that involves an agent, yours or your users’, add one line per task: which rung it sits on, what receipt it leaves, and where the stop lives. If you can’t fill in that line, you’re not done with the spec. The agent will fill it in for you, and it tends to pick a high rung.