Here is the prediction that matters most: agents are going to break out of engineering and into the rest of the organization. Every company that has built a capable coding agent is going to look around and ask why their GTM team, their customer success team, their ops team do not have the same capabilities.
Non-engineering agents are easier to build in many ways. They do not need an environment set up. They do not need to know what stack you are on. They do not need a CI/CD system or a setup script. They can be ephemeral — spin up, do the work, spin down — without any understanding of a test suite or build pipeline.
But they introduce a different hard problem: organizational context. When you build an agent for a customer success team, it needs to understand the company's processes, products, customer segments, and standard operating procedures. It needs a living representation of how the company actually works. And it needs to surface disagreements. One person in the org might believe one thing about a process while the CEO believes something different. An agent that detects and surfaces those contradictions is genuinely valuable. This is not Glean-style organizational search. It is something more dynamic — a knowledge layer maintained through interaction rather than documentation.
Customers will want this on their own infrastructure, with their own data, connected to the tools they already have. Nobody wants to force their ops team onto a new platform. The agent has to work with SharePoint, with Slack, with whatever weird stack the company has assembled over the last decade. Glass is the case study that crystallized this for me. Same company, two products. Their engineering-focused agent is heavily bought off the shelf. Their non-engineering agent is the opposite — lightweight, built with pre-commit hooks and Slack channels, almost no purchased infrastructure. When the requirements get light enough, a Slack channel with a bot and some hooks goes surprisingly far.
The pattern that will play out is the Airflow pattern. Some team inside a company builds an agent platform for their own use. Another team piggybacks. Then three or four more teams come. Suddenly they have an internally hosted agent service with SLAs, and they never wanted to be in the platform business. That is when they look around for something purpose-built. I've argued elsewhere that the platform play is to catch buyers before they become builders — and the org-wide agent layer is exactly the moment that gradient bends in your favor.
Sources
Related Essays
The Primitives Are the Same Across Roles
Sandbox, tools, prompts, governance — the primitives are universal. Engineering agents and GTM agents share the same engine. Only the body changes.
The Grayscale Between Engineering and Everywhere Else
There is no clean split between coding tools and business tools. The reality is a grayscale, and the products that win serve the whole spectrum.
Start With Workflows, Not Roles
Role-based agents start with the hardest version of the problem. Workflow-first agents start small, ship in a week, and compound into something larger.
Key takeaways
- Agents will break out of engineering and into GTM, customer success, and ops. Every company that built a capable coding agent is about to ask why the rest of the org does not have one.
- Non-engineering agents are easier to build — no environments, no CI/CD, no test suites — but they need a living representation of how the company actually works.
- The hard problem is organizational context. Standard operating procedures, customer segments, and even disagreements between stakeholders need to be surfaced and maintained.
- The Airflow pattern will play out: one team builds an internal agent platform, others piggyback, and they accidentally end up running an SLA'd service they never wanted to operate.
FAQ
Why are non-engineering agents easier to build than coding agents?
They do not need an environment, a stack, a CI/CD pipeline, or a test suite. They can be ephemeral — spin up, do the work, spin down — without the heavy infrastructure that coding agents demand. The hard part is not execution; it is teaching them how the company actually operates.
What is the organizational context problem?
Non-engineering agents need a living representation of how the company works — processes, products, customer segments, standard operating procedures. They also need to surface disagreements when one stakeholder believes one thing about a process and the CEO believes another. That knowledge layer is the hardest unsolved problem in the space.