AI agents in CRE: build the infrastructure before you hire them
I held off on AI agents when I started building with AI. They were capable. I wasn't ready.
An AI agent is only as safe as the environment it works in. Before an agent gets real work, decide which of its limits the system enforces and which it is trusted to follow, and put every action you cannot undo in the first group.
The short version: I run my firm's internal work on a team of AI agents, each with a role, a manager and a list of things it cannot do. Those limits come in two kinds. Hard rules are permissions the system enforces, whatever the agent decides. Soft rules are written instructions the agent reads and follows. The test for which kind a rule needs is whether you could afford a deviated outcome or undo the damage if the agent ignored it. The agents build and execute, and they bring me in for money, anything sent in my name and anything that cannot be taken back.
What is an AI agent, in practical terms?
An AI agent is a model working toward a goal with tools, choosing its next step inside limits someone set, and stopping at a gate where a person approves. A chat window answers what you paste into it. An agent acts: it opens files, writes to systems, starts work and hands it to the next agent. When a chat window gets something wrong, you get a bad answer. When an agent gets something wrong, something typically breaks. The limits matter more than the model.
Why wait before putting AI agents to work?
Agents need a stable structure to work inside, and I did not have one yet. I was still laying the foundation, conceptually and architecturally: what I wanted to build, where the data lives, who can change it, and how a change gets recorded. An agent dropped into that would have been making decisions inside a structure that was still moving under it. Once the structure held still, the question changed from "can an agent do this?" to "what is it allowed to do, and what stops it?"
What is the difference between a hard rule and a soft rule for an AI agent?
A hard rule is a permission the system enforces, and a soft rule is an instruction the agent reads and follows. The difference only shows up when an agent decides to do the thing anyway. A hard rule still holds. A soft rule depends on the agent.
| Hard rule | Soft rule | |
|---|---|---|
| Where it lives | In the system's permissions | In an instruction file the agent reads |
| If the agent ignores it | The system refuses the action | Nothing stops it |
| What it takes to change | A deliberate change to permissions | An edit to a text file |
| Use it for | Anything you cannot undo | Process, judgment and role boundaries |
Here is a hard rule from my setup. My agents log in to the database with an account that cannot edit a table directly. As of October 5, 2026, that account can run 58 approved functions and holds zero permissions to insert, update or delete a row on its own. Each of those functions records what it changed. The agents that draft my content are narrower still: they can call 10 functions, and recording a decision is not one of them. They can propose a decision. They cannot record one.
Here is a soft rule. My test analyst finds bugs in the deal software, reports them and never fixes them. Fixing belongs to the product manager, so the agent checking the work is never the one that wrote it. That rule is a line in its instruction file. Nothing technically stops it from editing the code. It doesn't.
How do you decide whether a rule should be hard or soft?
Decide by asking two questions: what is the worst that can happen if the agent ignores the rule, and can you undo it? If the worst case is small and reversible, a soft rule is usually enough, and it is far cheaper to write and to change. If the worst case is large or permanent, write it as a permission. Soft rules work most of the time, and most of the time is a fine standard for how a memo is formatted. It is the wrong standard for a wire.
In deal terms: a rewritten draft memo is reversible. An email to a lender, a deleted deal folder, or a number changed after an investor has seen it is not.
When should an AI agent bring a person back in?
An agent should bring a person in for the decisions that are that person's to make, and act on the rest. In my setup those are money, anything sent in my name, and anything that cannot be taken back. Everything else the agents do and then report, listing each call they made on their own and why. When one makes a bigger build decision by itself, it goes on a separate branch that I review before anything becomes permanent.
The split mirrors a good analyst and a principal: the analyst runs the model, and the principal signs the LOI.
What goes wrong if AI agents get work before the infrastructure is ready?
When AI agents get work before the infrastructure is ready, their mistakes move as fast as they do, and some of those mistakes cannot be undone. Think of a first-week analyst. You would not hand them the wire instructions and the investor list, however strong their resume. An agent with full access and no rules is that analyst, with nobody having decided in advance which of its actions are reversible.
The order that worked for me: decide where the data lives, decide who can change it and how each change gets recorded, sort the rules into hard and soft, and only then hand an agent real work.
Build the environment first. Then hire the agents.
This is part of what I teach in the CRE AI Apprenticeship. The data infrastructure, and AI rules and execution. See here: alphacre.io/apprenticeship