There is a persistent myth that you need two separate products: one for engineers, one for everyone else. A coding tool and a business tool. Left door or right door. This is wrong. The reality is a grayscale.
Consider a company running both an engineering agent and a non-engineering AI co-worker. The engineering agent required the full stack: sandboxes with VNC and Chromium, Modal compute, complex orchestration. The non-engineering co-worker? Slack channels and pre-commit hooks. Same company, radically different infrastructure needs. Same buyer, same budget line, but a product split would have forced two purchases and two integrations for a single coordinated rollout.
Non-engineering agents are simpler precisely because they do not need environment setup. They do not need to know your stack. They do not need CI/CD or test suites. They can be ephemeral — spin up, do the work, spin down — without maintaining state about a complex dev environment.
But they still need to be defined in software. They still need context. They still need to execute code when an API call is not enough. They still need review infrastructure so a human can verify output before it goes anywhere consequential. The shared substrate is real — it is the same primitives I described in review as a primitive and the declarative atomic agent. The differences are about which primitives you light up.
Treat this as binary — Cursor or Zapier — and you end up in an uncanny valley. Too complicated for business users, too simple for engineers. Design composable primitives with flexible artifact types and you serve the entire spectrum without building separate products.
If you are building in this space, the test is whether your platform can host both a code-shipping agent and a Slack-summarizing one without forking the architecture. The companies that pass that test will absorb the next wave of demand as agents move past engineering. The ones that fail it will end up with two half-built products competing for the same internal team.
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.
Agents Are About to Break Out of Engineering
Non-engineering agents are easier to build but harder to contextualize. The organizational knowledge layer — not the execution layer — is the real unsolved problem.
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
- The myth that you need separate products for engineers and everyone else is wrong.
- Engineering agents need full sandbox stacks. Non-engineering agents need Slack and pre-commit hooks. Same company, different infra.
- Composable primitives with flexible artifact types serve the whole spectrum without separate products.
FAQ
Why is the binary split wrong?
Because real workflows live on a spectrum. The same company runs both an engineering agent that needs a sandbox and a non-engineering agent that lives in Slack. Splitting the product splits the platform investment.
What is the design move?
Composable primitives. Define artifact types, review surfaces, and orchestration as first-class concepts. Compose them into use-case-shaped products on top. One platform, many product surfaces.