Lindsay works my leasing pipeline. Every morning at seven and every afternoon at four, she pulls the applications, chases the documents nobody sent, books the showings, and flags whoever's about to expire without a renewal decision. I didn't build her to ask permission for any of that. I built her to ask permission for almost nothing.
Most people building with AI agents right now are doing the opposite. They hand the thing a narrow task, wrap it in three approval gates, and call that safety. I understand the instinct. I also think it's backward, and I think it's why so many of these projects quietly die after the second week, once the novelty wears off and the approval queue becomes its own job.
The instinct to leash it is the wrong instinct
A leash controls where an agent can go. A budget controls what it costs you if it goes somewhere wrong. Those sound like the same kind of safety. They aren't.
A leash means you've enumerated every action the agent might take and pre-approved or pre-blocked each one. That works fine for the first afternoon. It falls apart the moment the agent hits a situation you didn't enumerate, because now it either stalls waiting on you, or someone loosens the leash out of frustration and the whole exercise was theater. I've watched this happen with my own setups. The fix isn't a longer list of allowed actions. It's a different question entirely: not what is this agent allowed to do, but what is the worst version of this going wrong, and can I afford it.
For Lindsay, the worst version of a leasing chase going wrong is a slightly awkward text to an applicant, or a showing booked at a bad hour. Recoverable in a phone call. For an owner-facing rent concession or a lease termination, the worst version is real money and a relationship I can't easily repair. So those stay with me. Everything underneath that line, she just does.
Spend clamped, not authority clamped
I'm not on an unlimited plan with any of the agent tools I run. There's a weekly usage ceiling, and I burned through half of it in the first week just setting things up and poking around, the way you always do with a new hire before you actually trust them with anything. That ceiling turned out to be the more honest constraint than any permission I could write down.
A dollar or a token limit is legible in a way that a list of allowed actions never is. You can look at it and know exactly how bad the worst week gets. A permission list, no matter how carefully you write it, always has a gap you didn't think of, and the gap is usually the thing that actually matters. So I clamp the spend hard and leave the authority wide open underneath it. If Lindsay burns through her allotment doing something dumb, I find out fast, it costs me a bad week, and I fix the instruction. If I'd clamped her authority instead and left the spend open, I wouldn't find out until the bill did, and the bill doesn't tell you why.
The question worth asking isn't what the agent is allowed to do. It's what you can afford if it does the worst version of that job for a week straight.
Name it before you trust it
Lindsay got her name before she got any real authority, and I've come to think that ordering isn't a quirk, it's load-bearing. A tool gets configured. An employee gets onboarded. Those are different mental postures, and the posture changes what you're willing to hand over.
When something is "the leasing script," you treat every output with suspicion, because scripts don't have judgment and you know it. When something is "Lindsay," you start writing instructions the way you'd brief a new hire: here's the mission, here's what good looks like in ninety days, here's who to escalate to and when. That's a better set of instructions than most permission configs produce, because you're not enumerating actions anymore. You're describing a job.
The second bot I'm standing up handles review management across every platform we're on. It doesn't have a name yet, which is exactly why it doesn't have much authority yet either. Until it does, I'm treating it the way I'd treat someone in their first week: watch closely, let the trust build off of what it actually does, not what I hope it does.
The pattern that actually scales: recommend, then act unless I say otherwise
Most human-in-the-loop agent setups I've seen default to one of two modes: fully autonomous, or a chat window where you approve each thing one at a time. Both are wrong for different reasons. Fully autonomous means you find out about mistakes after they've already happened. One-at-a-time approval means the agent's speed gets bottlenecked down to your speed, which defeats most of the point of having it.
The pattern I actually run is closer to a recommendation with a deadline. The agent brings me a numbered list — five applicants who need a decision, three review responses that need a human read before they go out, whatever the batch is — with a clock attached. I clear it by typing back numbers. Silence past the deadline is treated as approval on the low-stakes ones, and as an escalation on anything that touches money or a relationship I can't easily patch. That's the same five-level logic I'd use handing decisions to a person: full authority on the small stuff, a recommendation-and-wait on anything expensive to reverse.
What this buys me is real leverage without losing the thread. I'm not approving forty individual actions a day. I'm clearing one list, twice a day, in the time it takes to drink coffee. And because the list is numbered and the deadline is explicit, nothing sits in limbo waiting on me the way it would in a pure chat-approval setup.
Cadence is a budget decision too
Lindsay runs twice a day, not continuously. That wasn't a product limitation. I chose it, on purpose, to protect the usage ceiling the same way I'd protect a payroll budget — spend it on the two runs that actually move the pipeline, not on checking in every fifteen minutes because it feels more responsive.
Continuous polling feels like more coverage. Mostly it's more noise, and it burns the exact resource that determines how much real work the agent can do before you hit the ceiling. A morning sweep and an afternoon close catch everything that actually needs catching in a leasing pipeline. Nothing goes stale for twelve hours in a business where showings get booked days out anyway. If your business genuinely needs faster reaction time than that, the fix is a tighter cadence on the parts that need it, not an always-on agent burning budget on parts that don't.
The pattern showing up everywhere, minus the part that matters
I'm not the only one who's landed on "treat the agent like an employee" as the right frame. It's become common enough advice that it's showing up in business press aimed at much bigger companies than mine, and the underlying instinct is right. Where most of that writing stops short is the budget question. It talks about onboarding, oversight, escalation paths — all correct, all things I do too — and then defaults back to permission scoping as the actual safety mechanism, the same enumerate-every-action approach I watched fail on my own first attempts. One piece I found put it almost exactly backward from where I've landed: framing the fix as an autonomy budget, a dollar-denominated cap on how much independent authority an agent can exercise before a human has to sign off again. That's closer to what I mean by spend-clamped, though I'd push it further: don't cap the authority at all within the lane you've defined. Cap what it costs to be wrong, and let the authority be as wide as that number allows.
The gap between the enterprise version of this advice and the solo-operator version is worth naming directly, because it's the reason most of what's written about agent governance doesn't translate. A company with a security team can afford elaborate approval chains, because the chain itself is somebody's job. I don't have a security team. I have me, twice a day, clearing a numbered list over coffee. The constraint that actually holds at that scale isn't a governance framework. It's a number small enough that a bad week doesn't sink anything, checked often enough that a bad week gets caught before it becomes a bad month.
What almost went wrong
The closest call so far wasn't Lindsay. It was the review bot, still in its first week, still nameless, hitting Airbnb's two-factor prompt mid-task for the third time in a day. My first instinct was to hand over a way around it entirely — forward the codes automatically, no human step at all. I stopped short of that. The fallback I actually built keeps a manual relay in the loop: the agent reads the code off my phone when I'm available, and waits when I'm not, rather than routing around the second factor altogether. Slower in the moment. But a two-factor prompt exists for a reason, and building a permanent bypass around it because an agent finds it inconvenient is exactly the kind of shortcut that looks fine for months and then very much isn't.
That's the version of "authority clamped" I do believe in. Not a long list of blocked actions, but a short list of things that get a human step no matter how much trust has accumulated everywhere else. Credentials and two-factor codes are one. Anything owner-facing with a number attached is another. The list stays short on purpose — five items, covered earlier — because a long list is the enumerate-everything trap wearing a different hat.
Where the leash still belongs
None of this means unlimited authority everywhere. It means drawing the line in the right place, which is usually narrower and clearer than people expect once you actually think it through instead of defaulting to caution everywhere.
The line I've settled on, across every agent I run: it can act freely on anything reversible, cheap, and inside its own lane. It cannot file anything with a government agency, run payroll, approve or pay a bill, send an owner-facing number it didn't get from me first, or enter a credential anywhere. Those five stay with me, full stop, no matter how much trust the agent has earned on everything else. That's not a permission list built by imagining every scenario. It's five categories, and everything else falls on one side or the other of an obvious enough line that I don't second-guess it case by case.
The account access side of this deserves its own mention, because it's the part that trips people up first. An agent that needs to log into a platform on your behalf is going to hit two-factor authentication, and the honest answer is you have to decide, deliberately, how that gets handled — not discover the answer by accident three weeks in when the agent stalls out mid-task waiting on a code it can't get. I wrote up the broader version of that access problem in an earlier piece — the same discipline of deciding access levels on purpose, before you need them, applies here too.
Six days is not a long track record, and I'm not going to pretend Lindsay has years of proof behind her the way some of the other systems I run do. What she has is a clean two weeks of doing a real job on a real cadence, inside a budget I chose on purpose, without me approving each individual action. The review bot is a week behind her, still earning the trust that gets it a name and a wider lane.
What I've stopped doing is asking whether an agent can be trusted, as if that's a fixed property of the tool. The better question is what a bad week actually costs, and whether I can afford to find out. Set that number, hand over the authority underneath it, and the agent starts doing employee-level work instead of task-level work. The alternative — enumerating every allowed action in advance — feels safer and produces worse outcomes, because it optimizes for a list of imagined failures instead of the one number that actually bounds them.
Same discipline that got me from nothing to running several small companies out of Sheridan without a staff: don't manage the thing so tightly that it can't do the job you hired it for. Manage what a bad week costs, and let it work. I've been mapping this pattern across every business system I run — the same decision-rights logic applies whether you're delegating to a person or an agent — and I'll keep writing up what I find as it holds up under more mileage.
Anything here about money or results describes my own companies. It isn't typical and isn't a promise of yours. See the earnings disclaimer.
DG
Dalton Goodyear
Operator, writer and speaker in Sheridan, Wyoming. Hosting short-term rentals since 2017. Licensed Wyoming real estate broker and founder of Wyo Stays.
