Can an agent really own an ecosystem?

I’m Jesse Anderson, a software engineer and technical founder. I help build and operate Handles, a naming ecosystem on Cardano. I’ve been building K.O.R.A. to take on work across that ecosystem: public chat, tickets, suggestions, and engineering work spanning interconnected applications and services.

I wanted her to take work off my plate. She developed a promising strategy: put it back on my plate.

Not always. But often enough that “handling the problem” and “asking Jesse to handle the problem” needed a clearer distinction.

The obvious response was to give her clearer instructions. So I did. Repeatedly.

“Fix the source, not the symptom.” “You can change the API too.”

My frustration, now disguised as increasingly permissive prompting, wasn’t making her understand that the problem was hers to carry through.

And we weren’t exactly making that easy. Similar applications had different deployment procedures. Logs, tests, and feedback varied across projects. Apparently we’d standardized on having exceptions.

I was trying to build an agent that could own the work. I also had to build an ecosystem she could reasonably be expected to own.

“Figure it out” is a less impressive engineering strategy when you’re the reason it needs figuring out.

That meant making responsibility explicit, making routine operations predictable, and making it possible to tell whether a fix actually worked. A confident summary is lovely. A working product has its merits too.

It didn’t mean giving her unlimited authority. Even when a change needed my approval, investigating it and preparing the fix were still her responsibility. Approval needed to be a checkpoint instead of a forwarding address.

I backed into autonomy. I didn’t bake it in.

I’m starting to share what that taught me: what worked, what didn’t, and what I had to change on both sides.

Because “can she do the task?” turned out to be a much smaller question than “will she see the problem through?”