It's clear to me that Zhc would be most successful in an non legacy environment. Even my small little company has such a patchwork of legacy systems that the friction of AI agents operating is overwhelming. Starting from scratch you can build everything locally and build exactly what you need without all the cruft of saas programs designed for many companies. Whatever the product is I'd imagine it to be something that I'd highly prioritize repetitious. This ai agents can excel at and you can fine tune for minimal glue.
I agree that greenfield makes this materially easier. But I’m starting to think greenfield doesn’t necessarily have to mean a brand-new company.
Even inside an existing company, you can take one bounded area and build a new system alongside the old one, get it working, and only then switch the work over. A bit like replacing a wing on a plane that still has to keep flying — you can’t stop the company, but you also don’t have to keep patching the old structure forever.
I’m less convinced about building everything locally, though. I still see a lot of value in best-of-breed tools if they expose good APIs and can be connected cleanly. The integration and state-sync tax is real, and AI or tools like n8n can reduce it, but they don’t make it disappear.
Same with repetitive work: it’s obviously easier to automate, but what interests me most about AI starts where the work is no longer fully repetitive.
I’m also increasingly thinking that the traditional “role” may be the wrong unit of design for an AI-native company. A role bundles many very different activities together. It may be more useful to break the company down activity by activity and decide what belongs to AI, deterministic systems, or humans.
I think that distinction is important. I’m not sure a person necessarily has to own every step — but the outcome, authority boundaries, validation and escalation path have to be explicit.
Otherwise you remove the human glue but create an accountability gap instead. I’m increasingly interested in how much of that ownership can be designed into the system itself, rather than attached to a person.
Designing it into the system is where I'd start too, but escalation is the part that keeps needing a name. Which of the four has been hardest to make explicit without a person attached?
It's clear to me that Zhc would be most successful in an non legacy environment. Even my small little company has such a patchwork of legacy systems that the friction of AI agents operating is overwhelming. Starting from scratch you can build everything locally and build exactly what you need without all the cruft of saas programs designed for many companies. Whatever the product is I'd imagine it to be something that I'd highly prioritize repetitious. This ai agents can excel at and you can fine tune for minimal glue.
I agree that greenfield makes this materially easier. But I’m starting to think greenfield doesn’t necessarily have to mean a brand-new company.
Even inside an existing company, you can take one bounded area and build a new system alongside the old one, get it working, and only then switch the work over. A bit like replacing a wing on a plane that still has to keep flying — you can’t stop the company, but you also don’t have to keep patching the old structure forever.
I’m less convinced about building everything locally, though. I still see a lot of value in best-of-breed tools if they expose good APIs and can be connected cleanly. The integration and state-sync tax is real, and AI or tools like n8n can reduce it, but they don’t make it disappear.
Same with repetitive work: it’s obviously easier to automate, but what interests me most about AI starts where the work is no longer fully repetitive.
I’m also increasingly thinking that the traditional “role” may be the wrong unit of design for an AI-native company. A role bundles many very different activities together. It may be more useful to break the company down activity by activity and decide what belongs to AI, deterministic systems, or humans.
Taking the glue out of the company is the useful cut. The miss I keep seeing is the handoff when an agent acts and no person owns that step.
I think that distinction is important. I’m not sure a person necessarily has to own every step — but the outcome, authority boundaries, validation and escalation path have to be explicit.
Otherwise you remove the human glue but create an accountability gap instead. I’m increasingly interested in how much of that ownership can be designed into the system itself, rather than attached to a person.
Designing it into the system is where I'd start too, but escalation is the part that keeps needing a name. Which of the four has been hardest to make explicit without a person attached?