How to Build Agents That Behave Themselves

Ron Reynolds · 2026-03-01 · 9 min read

By Ron Reynolds, Founder of ComOS Everyone's building agents. Not everyone's building agents that behave.

The default conversation right now is about capability. Can the agent book a flight? Can it write code? Can it negotiate a deal? Those are interesting questions. But they're the wrong first question.

The right first question is: what happens when the agent is wrong?

Because it will be wrong. Every agent, no matter how capable, will eventually face a situation it shouldn't handle alone. The question is whether your system knows that before the customer does.

I've spent fifty years building software systems. The lesson that keeps proving itself is this: reliable systems aren't built from brilliant components. They're built from well-governed ones.

That's as true for AI agents as it was for microservices, distributed databases, and every other technology that promised to change everything. What "Well-Behaved" Actually Means

A well-behaved agent isn't a dumb agent. It's not an agent with a longer system prompt or more guardrail instructions bolted on. It's an agent operating inside a system that makes good behavior the path of least resistance.

Think about what makes a great employee reliable. It's not that they're the smartest person in the room. It's that they: Know what they're authorized to do — and don't exceed it Know when to escalate — and actually do Can explain their reasoning — after the fact, to anyone who asks Learn from correction — without taking it personally Don't go dark — if they're stuck, someone finds out

That's the bar for agents too. And right now, almost nobody is building to it. Principle 1: Agents Need Boundaries, Not Just Instructions

Instructions tell an agent what to do. Boundaries tell it what it can't do — and what to do instead.

When we built ComOS, every agent operates within merchant-defined policy boundaries. Not suggestions. Not guidelines in a prompt. Hard structural limits enforced before execution.

A pricing agent can't raise prices beyond the merchant's configured maximum. Period. Not because the prompt says "please don't exceed the limit." Because the decision validator rejects the action before it executes. The agent can be as creative as it wants inside those walls — but the walls don't move unless the merchant moves them.

This matters because prompts are suggestions. Architecture is law.

A merchant running our system can configure each agent independently: Maximum price change without approval Maximum refund amount Daily action caps Escalation triggers for high-value decisions

The merchant decides the boundaries. The agent operates within them. The system enforces them. Three separate concerns, three separate layers. That's how you get behavior you can trust. Principle 2: Confidence Is a Score, Not a Feeling

Here's a pattern I see everywhere: an agent takes an action, the developer asks "was it confident?", and the answer is... vibes. The model seemed sure. The output looked right. No hedging language.

That's not confidence. That's hope.

In our system, confidence is a number — calculated from four weighted factors before every decision: Data quality (25%) — Is the input complete and reliable? Pattern match (25%) — Does this situation match known patterns? Risk level (30%) — What's the cost of being wrong? Historical accuracy (20%) — How has the agent performed in similar situations?

That score determines what happens next. Not the agent. Not the prompt. The score.

Above the threshold? Execute. Below it? Ask a human. Way below it? Escalate immediately.

The default threshold is 0.8 — high enough that the agent needs strong signals across all four factors before acting autonomously. For fraud detection, the bar is even higher at 0.9 — because the cost of a false negative is catastrophic. Different domains can be tuned as the merchant builds trust with the system. Principle 3: Escalation Is a Feature, Not a Failure

Most agent systems treat escalation as an edge case. Something went wrong, so now a human has to deal with it. That framing is backwards.

Escalation is the most important feature of a well-behaved agent. It's the mechanism that says: "I know what I don't know."

In our architecture, escalation is a three-tier system designed so that no decision gets stuck:

1. Merchant gets notified first. They have 24 hours to approve, reject, or modify. 2. If they don't respond, support picks it up with a 4-hour window. 3. If support doesn't act, platform admin gets it with full context.

The architecture is built so that every uncertain action has a path to resolution — and tracks who responded, when, and what they decided.

This changes the psychology of the system entirely. The agent doesn't need to be right every time. It needs to be right about whether it's right. That's a much more achievable bar — and it's the bar that makes autonomous operation safe.

A customer sends a return request 45 days after purchase. Policy says 30 days. The agent could deny it — but the customer's sentiment is negative, the data is clean, and this is a judgment call, not a clear-cut case. Confidence: 62%. The agent doesn't act. It suggests a path — "deny the return, offer 20% store credit" — and surfaces it for human review. Support approves the store credit in 15 minutes. Customer saved. Relationship preserved.

That's well-behaved. Not because the agent made the right call. Because it made the right meta-call: this isn't mine to decide alone. Principle 4: Every Action Needs a Receipt

If you can't explain what an agent did and why, you don't have an agent system. You have a liability.

Every action in our system generates a full audit record: the inputs it received, its reasoning factors, the confidence score, the action taken, and the outcome observed. Not because we're paranoid. Because accountability is the foundation of trust.

When a merchant opens their dashboard and sees that the Dynamic Pricing Agent adjusted headphone prices overnight, they don't see "AI adjusted price." They see the specific signals — demand velocity, competitor data, margin impact — the confidence score that triggered autonomous execution, and the reasoning chain that led to the decision.

The merchant can agree, disagree, or override. Each response is recorded. Over time, this audit trail becomes the merchant's clearest window into how their agents are performing — and the foundation for deciding when to give them more autonomy.

Transparency isn't a feature you add later. It's the architecture that makes everything else work. Without it, autonomy is just a black box with a credit card. Principle 5: Reversibility Is Non-Negotiable

Well-behaved agents make mistakes. The difference between a trustworthy system and a dangerous one is what happens next.

Every action type in our system has a defined rollback window. Pricing changes get 24 hours. Inventory adjustments get 2 hours. Some actions — like refunds already sent to a customer — are inherently irreversible, which is precisely why those actions require higher confidence thresholds and tighter policy boundaries to execute autonomously in the first place.

The architecture accounts for the difference. Reversible actions can have wider autonomy. Irreversible actions get more scrutiny. The system knows which is which.

This is the thing that unlocks merchant willingness to increase autonomy over time. When you know that most mistakes are recoverable, you're willing to let the agent try more. When mistakes are permanent, you keep the agent on a short leash forever — or you make sure those actions don't happen without human approval.

Reversibility isn't a safety net. It's a trust accelerator. Principle 6: Good Agents Get Better. Bad Agents Stay the Same.

The last piece — and the one most people skip — is the feedback loop.

Our intent classification system has a real learning loop: merchant corrections feed directly back into the model, improving accuracy over time. For agent decisions, we're building toward the same thing — merchant approvals, rejections, and overrides captured as structured feedback that tunes future behavior.

This is where the real compounding will happen. An agent that's been running for six months inside a merchant's policy boundaries, calibrated by their approval patterns and configured to their customer base — that agent will be worth more than a fresh deployment with a perfect prompt. Because it has context that no prompt can provide.

The architecture for this already exists: every decision records its inputs, outcome, and human feedback. The next step is closing the loop — making that feedback directly improve confidence scoring per merchant. We're not there on every agent yet. But the foundation is in place, and the direction is clear.

Well-behaved agents aren't static. They're adaptive within boundaries. The Compound Effect

Here's what all of this adds up to: agents that merchants actually trust to run their business.

Not because the agents are infallible. Because the system around them — boundaries, confidence scoring, escalation tiers, audit trails, rollback windows — makes autonomous operation reliable in a way that no prompt, no matter how well-crafted, ever could.

We run 32 autonomous agents in production on our retail platform alone, handling pricing, inventory, returns, customer support, fraud detection, and operational health. They're event-driven — reacting to orders, stock changes, customer signals, and system events through Redis Streams and scheduled jobs. They operate within merchant-defined policies. And they behave themselves — because the architecture doesn't give them a choice.

The agentic era isn't coming. It's here. The question isn't whether you'll use agents. It's whether the agents you use are well-behaved — or just well-prompted.

There's a big difference. And your customers will find out which one you built.