# Who Actually Builds AI Agents: the PM, the Engineer, or Both?

*Question — 2026-02-19 — by Mahmoud Zalt*

Engineers wire the agent, product managers shape what it does, and on small teams both jobs collapse into one builder using platforms like Sistava.

**Short answer.** Engineers wire the agent, product managers shape what it should do, and on small teams the two roles collapse into one builder. On modern platforms like Sistava, a non-technical founder can hire a pre-built AI Employee without writing code, which is the cleanest way to find out which parts of the build you actually need a human PM or engineer for.

## Who actually builds AI agents inside a team?

Inside a real team, AI agents get built by a small cluster of roles that share the work: an engineer wires the agent to models, tools, and data, a product manager defines what the agent is for and what success looks like, a designer shapes how a human talks to it, and a domain expert (sales lead, support lead, ops lead) supplies the playbook the agent is supposed to copy. In bigger companies these are four different humans. In a five-person startup, one founder often plays all four. The interesting thing about the current wave is that the engineering surface keeps shrinking: hosted platforms now ship the orchestration, memory, and tool calls out of the box, so the lines between PM, engineer, and operator blur faster than the org chart can keep up. The job titles still matter for hiring, but the actual build is much more of a team sport than the press releases imply.

## At a Glance

- **4** Core roles in a typical agent build (PM, engineer, designer, domain expert)
- **1** Founder often covers all four on a five-person team
- **~70%** Of the build is no longer custom code on hosted platforms
- **0** Lines of code needed to hire a pre-built AI Employee on Sistava

## What does the engineer actually do on an AI agent build?

The engineer on an AI agent build owns the parts that have to work even when nobody is watching. They wire the agent to a model (or several), set up the tool calls that let it act in the real world, choose where memory lives, and decide what happens when something fails halfway through a task. They handle the boring infrastructure: retries, rate limits, secrets, logging, observability, evaluation. On a custom build they write code in Python or TypeScript and lean on frameworks like LangGraph, CrewAI, or OpenAI Agents SDK. On a hosted platform they configure rather than code, but the same questions still need answering. The engineer is the person you blame when the agent silently spends a thousand dollars on tokens overnight, and the person you thank when it does not.

## Benefits

### Model wiring

Picks the model, sets temperature, handles fallback when the primary provider is down or rate-limited.

### Tool calls

Connects the agent to real systems: Gmail, Slack, Stripe, your CRM, your database, your browser.

### Memory layer

Decides where session memory, long-term memory, and the work journal live and how they are queried.

### Guardrails

Adds rate limits, budget caps, retry policies, and the kill switches that prevent runaway behavior.

### Observability

Wires Langfuse, Sentry, and dashboards so every decision the agent makes is traceable after the fact.

## What does the product manager bring to the agent build?

The product manager on an AI agent build owns the question the engineer cannot answer alone: what is this agent for, who uses it, and how do we know it worked. They write the brief, define the role (a sales SDR is a different agent than a support tier-one), map the workflow it has to execute, choose the success metric, and decide what the agent should refuse to do. They are also the ones who go talk to the human who used to do this job and find out what actually breaks in the real world, not the version drawn on a whiteboard. A good PM keeps the agent honest: scoped narrow enough to ship, broad enough to be useful, and instrumented enough that you can tell next month whether it is getting better. Without a PM you usually end up with a clever demo that nobody runs in production after week two.

### The five steps a PM owns on an agent build

1. **Write the role brief** — One page: what job the agent does, who it works for, which workflow it replaces, what it must never do.
2. **Define the success metric** — Pick one number that proves the agent worked (resolved tickets per week, qualified leads per day, hours saved).
3. **Shadow the human first** — Watch the human currently doing the work for two real shifts. The edge cases that kill agents live there.
4. **Set the scope boundaries** — Decide what the agent escalates to a human, what it refuses outright, what it has standing permission to do.
5. **Run the weekly review** — Read transcripts, label failures, feed the patterns back to the engineer and the prompt author every week.

The split sounds clean on paper, but in practice the two roles overlap heavily. The engineer ends up debating prompt wording. The PM ends up reading tool call logs. On small teams the same person wears both hats inside the same hour, and the title on their LinkedIn is whichever one their last company called them. The interesting question is not who has which job description, it is who is actually in the room when the agent ships.

If you are a non-technical founder reading this and wondering whether you need to hire an engineer or a PM first, the honest answer is usually neither, not yet. The current generation of hosted agent platforms (Sistava, Sintra, Lindy, a handful of others) lets you hire a pre-built AI Employee without writing a line of code or shipping a brief. You become the PM, the platform becomes the engineer, and you find out within a week what part of the build actually needs a human.

## Can a non-technical founder build an AI agent alone?

Yes, for most use cases a non-technical founder can build a useful AI agent alone in 2026, but only if they pick a hosted platform that ships the engineering work pre-done. The tradeoff is real: on a hosted platform you get an agent in production this afternoon, but you accept the platform's choices on memory, tools, and orchestration. On a custom build you keep every choice but need to either write Python yourself or hire someone who does. For a solo founder validating a workflow, the hosted path almost always wins because the question you are answering is not 'can I build an agent', it is 'is this agent worth building'. Once the workflow is proven and the volume justifies the cost, hiring an engineer to harden or extend it is a much cheaper decision than starting from a blank repo on day one.

## Benefits

### Hire a pre-built employee

Pick a marketing, sales, support, or ops role from a hosted roster and start a task in under five minutes.

### Connect real channels

Click through to wire email, Slack, calendar, and your CRM without touching an API key in code.

### Define the role brief

Write the one-page job description in plain English; the platform turns it into the agent's working prompt.

### Run the weekly review

Read the work journal, flag failures, adjust the brief, and let the agent get better without an engineer.

## When do you actually need to hire an AI engineer?

You need to hire an AI engineer the day the hosted platform stops fitting the job, not before. Three honest triggers: first, the agent has to call a system that no platform integrates with (a homegrown internal tool, a niche industry API, a regulated workflow), and you need real custom tool calls. Second, the volume or latency is now load-bearing for your revenue, and you need control over model routing, caching, and failover that a SaaS will not give you. Third, you need to embed the agent inside your own product as a feature your customers see, not as a back-office helper. Outside those three, a hosted platform plus a thoughtful founder-PM beats a custom build for the first six to twelve months. Hire the engineer when the platform breaks, not when the pitch deck does.

## Frequently asked questions

## FAQ

### Is building an AI agent a product manager job or an engineering job?

Both, in different parts of the build. The product manager owns the role brief, the success metric, and the weekly review. The engineer owns the model wiring, tool calls, memory, and guardrails. On a small team one person plays both. On a hosted platform like Sistava, the platform plays the engineer and you only need the PM half.

### Do I need a developer to build an AI agent in 2026?

Not for most use cases. Hosted AI Employee platforms let a non-technical founder hire a pre-built agent and put it in production without code. You only need a developer when you are building a custom integration, embedding the agent inside your own product, or running volume that justifies custom infrastructure.

### What does a product manager do on an AI agent project?

Writes the role brief, defines the success metric, shadows the human currently doing the work, sets the scope boundaries (what the agent escalates, what it refuses, what it can do without asking), and runs the weekly transcript review that feeds improvements back into the prompt.

### What skills does an AI engineer need to build agents?

Python or TypeScript, comfort with an agent framework like LangGraph or CrewAI, working knowledge of model APIs and tool calling, a feel for memory and retrieval, and the discipline to add observability and budget caps. The harder skill is product judgement: knowing when a prompt fix beats a code fix.

### Can one person build an AI agent end to end?

Yes, especially on a hosted platform. A solo founder can play PM, engineer, and operator within the same hour and ship a working AI Employee the same day. The constraint is not capability, it is attention: doing all three jobs well across many agents at once is where solo builders eventually hit a wall and need help.

The pattern that keeps showing up across teams I have watched build agents: the first version is shipped by whoever cares most, regardless of title. Sometimes that is the engineer who got annoyed at a manual task. Sometimes it is the PM who watched support drown. Sometimes it is the founder who decided this week is the week. The roles matter for scaling the practice, not for starting it. Start with the one job that hurts most this week, and the right builder usually self-selects.

The honest framing for the whole question: who builds AI agents depends much less on titles than on the size of the team and the maturity of the platform underneath them. In a fifty-person company you want a PM, an engineer, a designer, and a domain expert in the room. In a five-person startup you want a founder who can wear all four hats for the first version, then hand each one off as the workflow proves itself worth the salary. On Sistava and the small set of credible hosted alternatives, the platform takes most of the engineering off the table, which means the bottleneck moves to product judgement: knowing which job to delegate first, how to brief the role, and how to read the transcripts honestly. If you have that judgement, you can start today without hiring anyone.

**Tags:** ai-agents, who-builds-ai-agents, product-manager-ai, ai-engineer, ai-team-roles, non-technical-founder, ai-employees