Hadar BismutA question I keep coming back to lately: when the CEO announces the company is going AI-first, who actually turns that into practice? What will it look like in employees' day-to-day work?
Let's look at it together.
Use case 1
At Shopify, they built something called River: an AI agent that lives in the company's Slack and does everything. It reads code, runs tests, opens pull requests and reaches production data. In the last 30 days, 5,938 employees used it. One in every eight merged pull requests was written with River.
Impressive, and what makes it improve is even more impressive: the merge rate went from 36% to 77% in two months without retraining a single model. The reason: employees watched River work, saw where it got stuck, and helped it with the knowledge it was missing. Each team put its own standards into it, the tools it works with, and the way it thinks about its problems.
Tobi Lutke, Shopify's CEO, put it this way: "The agent gets better at being Shopify."
With River, knowledge that stays private helps no one. Tobi said it directly: "The company moves at the speed of its slowest secret."
Use case 2
At Ramp, an American fintech company, I saw the same thing from a different angle. The company reported reaching 99% AI adoption across all employees. One of the things they did to make that happen was build an internal marketplace called Dojo.
The idea: when someone on the sales team discovers a great workflow for analyzing customer calls and generating battlecards, she packages it as a skill and publishes it. From that moment, every other employee in the company can use it. Every skill goes through code review and versioning like regular code, and once it's live, it becomes the professional standard for its domain.
Finance, design, operations, sales: each domain builds its own shared foundation.
What these two stories teach us
In River, the agent worked according to the standards teams wrote, rather than instructions from above. In Dojo, the professionals in each domain decided what makes a good skill, rather than the agent. In both cases, the agent was as good as the standards fed into it. That's exactly what a guild does.
A guild is a shared layer
Guilds have been around for a long time. What's new is what AI requires them to be today.
A guild has always been the place where a profession defines itself: these are the tools we work with, this is what good workflows look like here, and this is the standard that holds us together. In engineering, in design, in data, in any profession spread across many teams that don't sit together.
What's happening now is that the guild has two audiences in one place: the professionals themselves, and the agents that work with them.
A designer who can fix a bug has more than a course behind her. She has access to engineering's standards, knows what's allowed and what isn't, and works within the building blocks engineering defined for itself. A Frontend developer who starts working on mobile too doesn't reinvent the wheel. They connect to a shared layer that already exists.
So the guild now produces more than knowledge for people. It produces the infrastructure that lets agents work to the right standards within the SDLC, reduces bottlenecks, and lets professionals move beyond the old boundaries of their role.
The more autonomy you want, the more infrastructure you'll need
This is the paradox not everyone notices.
Many companies think bringing agents into the organization solves problems. It can, as long as the agent has something to work with. River didn't improve by getting smarter. It improved because Shopify's teams invested in writing down what it needs to know. Dojo worked because professionals at Ramp took the time to package their knowledge and turn it into something shareable.
The more independent we want the agent to be, and the more freely we want professionals to move between domains, the stronger our shared infrastructure will need to be.
A good guild remembers two things at once: there's one deep profession to preserve and strengthen, and there's a shared layer that grows out of it and serves everyone, including the tools that come to help us.
Some of the standards can be written at the level of the AI Group or the infra team. But to make them specific to the teams, the different domains and the professional standards, we need the professionals themselves to do the work and update what doesn't work. That's a critical part of the process, which is also why we can't give up on people so easily.
This is a long process. And it's the difference between an organization that talks about the future of builders and an organization that builds the infrastructure that makes it possible.