At a Vanar roundtable this morning, founders and builders kept circling the same question: how much control should we really hand to AI? The answers were cautious. The infrastructure they described sounded surprisingly familiar.
I spent part of this morning sitting in on Vanar’s X Spaces roundtable, “Self-Running Businesses: Autonomy or Chaos?” The panel pulled together people from Gear Foundation, Corechain, Iridium, OORT, Moonrush, Ocean6, Aurex, SuperEx, BIGOD and others to talk about what happens when AI stops merely assisting with business and starts actively running pieces of one.
It was a useful conversation because it mostly avoided the breathless end of AI futurism. Nobody spent much time arguing about whether artificial intelligence is going to become sentient, replace civilization, cure mortality or decide it no longer needs us. Not one person discussed whether their toaster would eventually develop animosity toward them and resent its role in life. The discussion was much more practical than that.
Should an AI be allowed to spend money? Contact leads? Issue refunds? Negotiate? Hire or fire people? Move assets? Make decisions without waiting for a human?
Those are much better questions.
The host, Ify, joked early on that he basically wants AI to do everything so he can go sit on a beach. I sympathize deeply with this position. I would also categorize telling Claude to run your entire life today as a phenomenally bad idea.
Those two beliefs are not actually in conflict.
Autonomy should be earned
One of the strongest themes across the roundtable was that autonomous systems should not be given broad authority just because they are technically capable of exercising it.
Liviù Epure of Corechain offered a good rule of thumb. Before handing a task over completely, ask whether a mistake is reversible, whether the result is easy to verify and whether the amount at stake is small. If the answer is yes to all three, you probably have a decent candidate for autonomous execution.
That is a much more useful framework than asking whether AI is “good enough.”
Scheduling is a different risk than payroll. Reordering stock inside known limits is a different risk than signing a major contract. Drafting marketing copy is different from moving treasury funds. The relevant question is not simply whether the model can perform the task. It is how much damage a wrong answer can do before somebody notices.
Mehak from BIGOD described the idea as controlled autonomy. Let the system work. Give it defined commercial authority. Let it operate quickly inside that authority. Do not hand it unrestricted control over the company.
That struck me as the right way to think about the relationship because it is basically how my own use of AI has evolved.
About four years ago, I was pair coding with AI in the most literal sense. I was still writing most of the code myself and using the model when I got stuck, wanted a second opinion or needed help thinking through a problem. As the tools got better, I let them write more. For a while I still hand-checked essentially every line.
Eventually, the relationship changed again.
Today, for a lot of the things I build, manually reviewing every single line myself would not actually make the work safer. In some cases it would make it worse. Different AI models are now very good at reviewing one another’s code, challenging assumptions and finding weird edge cases that I may miss because I am too close to the thing I just built.
My role has shifted upward. I am less often checking whether a semicolon is in the right place and more often asking whether the system is doing what I intended, whether a dependency introduces risk, whether an assumption is bad, and whether the models disagree in a way that deserves my attention.
The autonomy expanded because trust emerged.
That, to me, is the sane path for AI in business too.
You do not begin by saying, “Here are the keys to the company. Good luck. I’ll be in the bar.”
You begin with bounded work. You observe. You verify. You let adversarial review find the weak spots. Then, when the system earns more trust, you give it a little more room.
Prompts are not guardrails
Alexander Rees-Evans of Iridium made another important distinction: telling an AI what it is allowed to do is not the same thing as technically preventing it from doing something else.
This is one of those ideas that sounds obvious once somebody says it out loud.
A prompt that tells an agent not to spend more than $1,000 is still just text. A system that fundamentally cannot authorize a transaction of $1,001 is something entirely different.
Rees-Evans described Iridium’s policy engine as a way to put hard boundaries around agent behavior: spending caps, approved addresses and other restrictions enforced outside the model’s own reasoning process.
That is a much more serious way to think about autonomous systems.
Models are nondeterministic. They can be manipulated. They misunderstand context. They sometimes confidently produce nonsense. Anybody who has used them extensively has seen some version of the experience where the model solemnly agrees never to do a thing and then finds a brilliant and exciting new way to do that thing five minutes later.
The answer cannot be to write the warning in bigger letters.
If an agent is going to control money or infrastructure, the boundaries should exist in the infrastructure.
That same point came up repeatedly throughout the panel. Give agents budgets. Give them approved ranges. Give them permissions. Give them circuit breakers. Create kill switches. Keep humans available for consequential decisions.
The goal is not blind autonomy.
It is useful autonomy with a fence around it.
Humans still need to own the consequences. Amen.
Luis Ramirez, Chief Growth Officer at Gear Foundation, returned several times to the question of responsibility.
His point was simple: automation does not eliminate ownership.
An agent may execute a task. It may manage routine workflows. It may make decisions inside a defined range. But somebody still designed that system, approved the boundaries and put it into production.
As Ramirez put it during the roundtable, when an AI makes a mistake, ultimately that remains a human mistake.
That matters because it punctures one of the lazier fantasies around autonomous business: that the machine somehow absorbs responsibility along with the work.
It does not.
If your agent sends money to the wrong place, violates a contract or starts insulting customers, “the AI did it” is a dubious business practice at best.
Ramirez also talked about human-in-the-loop systems, where an agent can proceed automatically until it reaches a point that requires explicit human judgment. At that point the workflow pauses, presents the question to a person, and waits.
That is a model I find much more believable than total autonomy.
The trick is not to keep a human clicking “approve” on every trivial action. That just turns the human into a very slow API endpoint. The trick is to reserve human attention for the decisions where judgment actually matters.
If an AI can successfully perform 10,000 routine operations, fantastic. Let it rock.
Bring me the weird one.
Bring me the ambiguous one.
Bring me the one where the financial exposure suddenly jumped by an order of magnitude.
That is where human attention is valuable.
Adversarial review is part of the system, not an optional extra
Ramirez also brought up testing, and this is an area where I think the AI conversation still tends to be too soft.
Autonomous systems should not merely be tested to prove that they work. They should be tested to find out how they fail.
If the system is supposed to stop and ask a human under certain conditions, deliberately force those conditions. If an agent has a spending limit, hammer the limit. If it is supposed to refuse a dangerous action, try to persuade it not to. If it relies on assumptions about data, deliberately feed it bad data.
This is where adversarial review matters.
If one model writes the code and the same model writes the tests based on the same assumptions, you may get a very tidy little closed loop where everything agrees with itself that everything is Gucci and everybody goes home happy.
Danger, Will Robinson.
Ify told a story about mentoring university students who had built an application using Claude with obvious problems. They assured him that it had passed more than a hundred tests.
Impressive.
Who created the tests?
Claude.
That is funny because it is also exactly the problem.
AI writes the implementation. AI writes the tests. AI checks the implementation against the tests it wrote. AI congratulates AI.
Excellent work, everyone.
A stronger system introduces disagreement on purpose.
Use another model. Use another reviewer. Use deterministic checks. Use real-world constraints. Try to break the thing. Then bring a human into the places where the reviewers disagree or the consequences are meaningful.
That is not a sign that AI failed.
That is how you build enough confidence to safely give it more authority.
Blockchain can help, but it does not confer wisdom
Max from Ocean6 offered a useful counterpoint to some of the blockchain enthusiasm.
Putting AI activity on-chain does not automatically make it trustworthy.
Correct.
A blockchain can provide transparency, verifiable state and enforceable constraints. It can show what happened and make certain actions impossible outside defined rules.
It cannot guarantee that an agent made a smart decision.
An immutable bad decision is still a bad decision. Having distributed consensus attest that, yes indeed, that bad decision happened does not magically make it a non-bad decision.
The useful role for blockchain here is narrower and stronger than the usual marketing pitch. It can provide a place where authority is explicit, execution is observable and constraints are enforceable.
That becomes much more important once AI graduates from suggesting actions to actually taking them.
At that point, boring questions become extremely important.
Which account can this agent use? How much can it spend? Which programs can it interact with? How long does the authorization last? What happens if it exceeds those limits? Can somebody stop it? Can we reconstruct exactly what happened afterward?
Those are not primarily intelligence problems.
They are infrastructure problems.
And this is where the Vara part gets interesting
I went into the roundtable expecting to hear a discussion about autonomous business and listen for anything specifically relevant to Vara.
By the end, something else stood out.
A surprising amount of what the panel described as infrastructure autonomous systems would need is infrastructure Gear and Vara have already been building.
For years.
That is the part worth sitting with.
Vara’s underlying execution model is built around actors communicating asynchronously through messages. Programs maintain their own state and communicate with users and other programs through that message system. Gear’s actor model was designed to support concurrent, asynchronous application logic rather than forcing everything into the more familiar pattern of a user manually triggering every discrete contract action.
Vara programs can also reserve gas for later execution and send delayed messages. That allows applications to perform deferred actions and, in some cases, send future messages to themselves rather than depending on an outside service to wake them up and tell them to continue.
That is kind of a big deal.
Because much of this architecture existed before the current AI-agent gold rush.
Vara did not need the phrase “agentic era” to invent software that can maintain state, communicate asynchronously, wait, resume and continue doing work.
Now the AI tooling is catching up with the architecture.
Vara’s current Skills tooling gives coding agents workflows for building, testing and deploying Vara applications, and the documentation explicitly supports tools such as Claude Code, Codex and Cursor.
That does not mean Vara has magically solved autonomous business.
It has not.
The panel raised plenty of problems that remain genuinely hard: policy enforcement, legal accountability, safe delegation of authority, adversarial testing, human escalation and the exact line between useful autonomy and dangerous overreach.
But there is a meaningful difference between designing a blockchain today because agents may eventually need somewhere to operate and realizing that a network that is already built and battle hardened happens to map unusually well onto the problem.
That is what stood out to me listening to this roundtable.
For much of the conversation, the panel was describing the ingredients that autonomous software would need: persistent execution, defined authority, constrained access, asynchronous workflows, human intervention, observable activity and the ability to continue working without somebody manually pushing every button.
That looks suspiciously like the Vara of today.
A lot of the plumbing is already there.
And that is why Vara’s current language around AI is more interesting than it might appear at first glance.
The documentation calls Vara “Built for the Agentic Era.” It goes further and says its current agent tooling is available “here and now, not on a roadmap.”
Not hypothetical. Live, right now.
Not we are going to build a blockchain for agents.
Not someday autonomous software will need this.
Built.
The newer agent layer is still evolving. The tooling will improve. The business models will get tested. Some ideas will work and some will almost certainly burst into flames in funny and expensive ways.
But underneath that experimentation is a live network with an execution model that has already been doing many of the things this panel spent the morning describing as being needed.
Maybe the question is not whether we eventually want AI to do almost everything.
I suspect we probably do.
The real question is how much autonomy the system has earned today, what guardrails exist around the authority we give it, and whether the infrastructure underneath it is capable of enforcing those limits when the model inevitably gets clever, confused or just plain wrong.
That is a much harder problem than telling Claude to run the company.
It is also the more interesting one.
And it reinforces something I have been saying about Gear and Vara for a long time: they did not build for where the ecosystem was. They built for where it was going.
Vara did not chase the agentic era. It looks increasingly like it was waiting for it to arrive. All aboard.