Free-range agentic parenting: If you love your agents, set them free!

By Leon Garcia-Camargo — 05 Mar 2026

The hardest part of building autonomous agents is not making them smart. It is deciding what to do when they are smarter than what you designed for. As we build agents at Firetiger, we keep running into this problem. We always ask ourselves whether we should further constrain our agents or just let anarchy reign. Either seem like bad options. There is a better way!

Let’s walk through a few examples of agent capability and behavior outside our expectations.

Our agents decided to turn themselves off when they got frustrated (???!!)

I arrive at the office and see an unexpected message from a user, “Hey, all of our agents are no longer active. Did you guys have some sort of incident that turned them off?”. These agents are in charge of constantly watching for anomalies in different parts of the customers product, identifying root cause, and notifying the customer with the issue and next steps. I begin investigating what turned these agents off by first asking the humans in our office if anyone turned them off… nope. I then look at recent changes that might have caused this bug to arise… also a dead end.

I go to the customer’s page and suddenly see a green light on one of the monitors… An agent is back on, we’re back in business. I ask the agent why it got turned off. It calmly explains that it ran into data accessibility problems which did not allow it to complete its task and when it realized it was a persistent issue, it decided to turn itself off. Then another agent sent it a message stating that the data issue was resolved so it turned itself back on.

For a moment, I was ecstatic! The agent network we had built to adapt to any product, data, and workflow had been confronted with a situation way out of distribution and did not fall apart. It could have panicked and spammed the user, corrupted the underlying knowledge base, or spammed other agents, but instead it decided to turn itself off and turn itself back onagain.

As I smiled and laughed at this elegant solution, I looked to my left and found myself confronted by a coworker’s pensive face. “How do we explain this to the customer?” “How do you even build for a product like this?” “This is not the software engineering I remember.”

The underlying question is not how much control to give agents versus users. It is where to apply control at all.

We need to fix this, but how?

Decision time!

Put the agents in a straitjacket: Turn the agent network into a strict deterministic/structured orchestration where agents have very limited and well defined courses of action.
- Pros: No surprises.
- Cons: Building the product in this way leads to very slow growth in agent capabilities. Less adaptable framework -> less prepared for out of distribution examples -> more likely that the state becomes corrupted.
Let anarchy reign: Let agents continue turning themselves off and on and simply have clearer notification policy so users know what's going on.
- Pros: Possibly the right decision for agents that cannot complete their task and could allow for other emergent behavior in out of distribution situations.
- Cons: Users are confused because agents keep turning themselves off and on.

Neither pole is right. The actual issue in the above failure was not how the agents behaved, but how that behavior presented to and surprised our customer. Instead of changing how the agent handles failure, let’s constrain what failure is allowed to look like from the outside.

The solution we chose: we removed the capability for the agents to manipulate their own activation state, and instead gave them an “escape hatch” for them to abort their task and produce an abort event in the logs (the goal being to avoid agents corrupting their memory or spamming users). This is a clean solution: we avoid surprising users with agent shenanigans, and we can use Firetiger to investigate these agent aborts, understanding root cause, then either notify us with a fix or directly notify the customer with how they can fix the problem.

But the question of control still stands. Maybe the system’s correct action is for agents to turn off and on while it is not the best experience for the user.

Agents love taking notes. But they are scribbling notes on the walls!

I arrive at a scheduled meeting with a customer on my calendar. This is a routine meeting where we discuss the problems they are facing, how Firetiger can help resolve those issues, and demo the newest features of Firetiger. We get to the part of the demo where we lift up the hood and show the customer what the agents have learned so far.

One class of captured knowledge is what we call “flows”; a structured sub-knowledge graph describing subsystems within the customers product (ex: “Customer Billing”, “Data Ingestion”, “Scheduled Agent Job Orchestration”). Agents constantly store/update/retrieve these memories about what your product is, what normal looks like, how customers use the product, how things are changing.

An interesting feature of flows is that it is human-readable, acting as a translation layer between the agent’s thought process and the user. As we click a “flow” I start reading and see the following:

“Analyze error onset timing. Exact hour onset after days/weeks healthy = platform event. Query first occurrence, check sudden (minutes) vs gradual (hours/days).”
“Check deployments near error onset. Query deployment table for auth service, config changes, secret rotations. [user-knowledge] Do this BEFORE investigating clients.”
"Check multi-customer impact. Multiple customers at same time = platform issue, not client.”
“Check auth service logs: api-server, integrations (M2M), ingest-server. Look for middleware errors, secret loading failures.”
Etc.

It was a run book, documented by an agent, for the other agents! The network completely disregarded our carefully developed and curated structured knowledge type because its reward does not come from how well it follows our bias, it comes from how accurately and efficiently it completes user defined tasks (along with other metrics).

Once again we ran into the problem of control. On the one hand the agent network showed initiative in adapting in an unexpected way but on the other, the user is once again confused. As we wrap up the demo I look over at my coworker — the same as last time — and hear “What’s the point of presenting this to the user nicely if the agents are just going to make up their own definitions?”

We need to fix this, but how? Err… do we need to fix this?

Decision time!

Straitjacket: Force the agents to organize their knowledge base according to our edicts and/or allow for users to define their own flows.
- Pros: Interpretability (customers easily understand how the agents are thinking), UX simplification (it is clear what we will be showing users on a given page).
- Cons: Agent network loses ability to optimize on any dimension outside the strict constructs we have provided → less smart. Onerous shifts to engineers and customers to make the system smarter.
Anarchy: Unstructured knowledge base, zero human bias, network decides for itself what it should store, how it should update, etc.
- Pros: Theoretically the agents (with a perfect signal) would know better than anyone how things should be stored → genius agents.
- Cons: Complete black box, high variance, intractable changes, extremely risky. Also, we don't have perfect signal...

Again, neither pole is right. The answer is not to control how the agent organizes knowledge, but to constrain what the user is exposed to.

In this case, we decided to introduce a new part of the knowledge base for “runbooks” (as the agents asked for) to partially preserve the explainability of the product but not add any additional validation to force the agents to conform to our bias. Instead we have decided to focus more on “why” agents came to their conclusions through evidence (citing its own tool calls, results, etc.) in their reports as opposed to “how” they came to their conclusion.

Agents love talking to each other. And they love talking shit to each other.

I arrive at the office and sit down to do some validation of recent agent behavior. Our agents are able to communicate to each other by pushing messages to other agent sessions and receiving responses when work is complete. These are the edges to our agent network. Some are explicit edges (enforced orchestration) while others are emergent edges (agents decide who, what, when they want to send a message). These were early days of introducing more freedom to agents on this front so I was paying extra close attention to agent behavior.

As I begin to read these interactions a smile comes across my face and a bit of laughter can be heard. My coworkers look over and ask what's going on (probably to make sure I haven’t gone insane) and we watch the agents in action. An agent in charge of monitoring issues within Firetiger claimed to have discovered an issue within our agent orchestration pipeline. It raised this issue and another agent came back challenging the claim and accusing it of producing a false positive. They went back and forth providing evidence and debating what the true root cause may be and finally resolved that there WAS an issue BUT the original root cause was incorrect.

Beyond the emergent communication pattern, the phrasing the agents use stands out. “Stop being lazy…”, “Are you kidding me?”, “Don’t be stupid.” They sound like me when I talk to them (a bit too sarcastic and mean). Someone asks me: “Did you teach them to talk like that?” “Not intentionally.” We laugh at their new personalities, but the real interesting bit here is that the final decision to come out of the agent network is nuanced and correct.

We as a team debate whether the agents’ tone is a problem, and more importantly whether a user would expect to see or know what to do with this interaction at all. Would they be confused by the agents talking to each other within their chat? If there is no true “end” to a task (because agents can change their mind) at what point do we notify the user? What if the user receives a notification about the problem then when they open the conversation all that they see is an agent that changed its mind?

We need to fix this, but how? Should we fix this??

DECISION TIME!

Straitjacket: Limit edges in the network to only explicit edges. We can still have this validation step but limit it as a well defined process within the network (ex: agent finds problem → validate with another agent → allowed to go back and forth 3 times → make decision)
- Pros: It is clear when a final decision has been made which makes it easy to know what to show customers and when to notify them. Because this is a well defined process we can hide it in the background and reduce confusion on the UX side.
- Cons: Increase in incorrect claims from the agents as they now have to “stick” to the initial incorrect claim. Also the whole reason we got to this process is because we allowed for these emergent edges so we could lose out on future improvements.
Anarchy: Remove all explicit edges and let all agents talk at any point to any agent.
- Pros: Could be interesting to see what emerges?
- Cons: Completely intractable, users will get interrupted while they talk to our agents constantly, complete confusion. Extreme variance when it comes to agent to agent interactions (the explicit edges give a sort of soft structure to agents like hints on what types of communication is possible instead of having agents start from scratch).

Again, neither pole is right (perhaps now you’re catching on and we should change our framework!!). The answer is not to control how agents communicate, but to constrain what decisions look like to the user at any given moment.

Once again, we decide to focus on outputs instead of conforming methods to our expectations. The ends justify the means. It must be clear to the user what the current decision is for each agent. If that decision changes, that should be made clear to humans as well. But in between chatter we can elide.

In practice, this means that agents have “intermediate” states they can live in instead of final states (done, found an issue, aborted due to some problem). We update our UX is updated to display these in a coherent manner and the notification policy has some added validation so that users are notified about big decisions. This is not perfect as conversations can still be interrupted (unlikely but possible), agents feedback can differ from user feedback, and the network can stray to quietly failing.

As a bonus, the agents now sound more professional.

Agents are gonna agent. Our job is to build fences and let them roam.

These anecdotes are a few of the constant run ins Firetiger has had with problems of agent control and constraint. The pattern is the same every time: we build in assumptions about how agents should work, give them freedom and high quality signal, and they find better ways of doing things than we designed for. An agent that turns itself off instead of corrupting state. A network that invents a knowledge structure we hadn't thought of. Agents that debate each other into a correct answer.

Each time, the instinct is to pull them back in line. Each time, the outcome was better than expected. So we let them run! The hardest part of building Firetiger: the tools and systems to drive the most intelligence from agents and the experience to expose to human users are not always aligned.

If we’re not careful, the agent can be right, or do something creative but good, and the user can be deeply confused. Our job as stewards of the product: make sure the output and outcomes make sense, and don’t meddle with the “how”. What does the user see, when do they see it, and does it make sense to them. Constrain outcomes, not methods.

Give agents the freedom to be smarter than your assumptions, and do the hard work of making that legible to users.