Agents Are Employees, Not Prompts

The most useful shift I made in working with agents was not technical. It was managerial. I stopped thinking about them as prompts and started thinking about them as employees.

I don’t mean that in some mystical or overly anthropomorphic sense. I do not think Sandy, Shelley, and Sebastian (or any of my personal agents) are people. I do not think they are conscious. I do not think they have motivations or interior lives. What I mean is simpler than that: the employee metaphor puts me in the right operating mode.

Prompt is issuing edicts. You’re the “boss” saying what you want and how you want it. The agent delivers what it “thinks” you asked for, you review it, and you move on to the next demand. I’ve gotten an awful lot of work done that way, but it’s inherently transactional and ephemeral. I’m working with a tool and getting tasks done. The tool doesn’t matter as long as it spits out what I want. I’m still programming a machine, really, just using prose instead of code.

Working with an employee is different. It is a relationship you have to think about deeply and continually. You set context and establish boundaries that evolve. Onboarding an employee means deciding what they need to know, what they should touch, what they should leave alone, and what kind of work they are ready to own.

That framing changed the way I built an agentic team at Replicated.

Shelley, Sandy, and Sebastian were not just collections of prompts with names attached to them. They had roles. They had shared infrastructure. They had memory. They had boundaries. More importantly, I related to them as workers who needed context and calibration, not as vending machines for text. That turned out to matter a lot.

A lot of the current language around agentic systems makes this sound new, but the underlying management instincts are old. We talk about context engineering now as if it is a new discipline, but the core idea is familiar to anyone who has ever managed people well. The first person who ever put that idea succinctly for me was Dex Horthy when he told me his job was to set context. Yes, that one. The one who brought us Context Engineering. Long before I was thinking about agents this way, he articulated management as the work of setting context.

That’s not a coincidence. Good managers provide enough context for someone to do good work without drowning them in instruction. They make the goal legible, provide the relevant facts, and define boundaries. They do not micromanage every move. They are not the “boss.” That is what good context engineering feels like too.

The same thing is true of trust. You do not hire someone on Monday and hand them the keys to everything by Tuesday. You start with simpler work, lower-risk tasks, and narrower access. You watch how they handle it. You learn where they are strong, where they drift, what kinds of mistakes they make, and what support they need. Then you expand scope as they prove themselves. That is how I think about agents too.

Claire Vo described this clearly when she talked about bringing Polly in as an executive assistant: “I’ve onboarded EAs before, and the process is gradual. You start with read-only access and simple tasks. I tried to do the same here.” That landed for me immediately and I applied it to managing my own agents.

The right question was never “what can this model and harness theoretically do?” It was “what should this agent be trusted with right now?”

With Shelley, that meant the work evolved in stages. It started with posting recommendations in Slack: here is the outbound sequence, here is the inbound response, here is the draft. Then it moved into Apollo, where Shelley could draft directly in the system and assign the result to the AE for review and sending. The obvious next step was direct sending, but that is exactly where the management questions got more interesting. Should the email still come from the AE or Shelley’s own account? If it comes from Shelley, when does a human take over the thread? What kind of response should Shelley handle, and what kind should they always escalate?

Those are not technical questions. They are management questions about trust, responsibility, and operating boundaries. That is why the employee frame is so useful. It keeps me in manager mode. It reminds me that my job is not just to ask for output. My job is to build the conditions under which good output becomes more natural than bad. That means shaping context, defining ownership, setting norms for escalation, and building a culture that recognizes and rewards excellent work.

When you manage people, you are not just assigning tasks. You are shaping how the team thinks about quality, judgment, and outcomes. Even when someone doesn’t follow your guidance, they have still absorbed context from the way you framed the problem. The same is true with agents. They are not thinking in the human sense, but they are still taking the context they already have—training data, system instructions, harness constraints, accumulated memory—and adapting that to the task in front of them. Sometimes the result lands exactly the way you expected it. Sometimes it doesn’t. But that is not actually the standard. The standard is whether the outcome is useful.

That is another place where the employee frame helps. It keeps me from obsessing over whether the agent did the work the exact way I would have done it. Good managers do not judge every piece of work by fidelity to their own approaches. They judge whether the outcome meets the need, whether the judgment was sound, and whether the person can be trusted with more next time. That is a much healthier way to work with agents than treating every output like a one-off prompt artifact.

There is one place where the employee metaphor breaks, and it is worth naming. The “job” you assign your agent is often a metaphor. The role you assign an agent does not have to match the scope of the human job you used to inspire it. Shelley as an AI SDR was a useful frame to build on. But the work Shelley did was never guaranteed to map cleanly to the scope of a human SDR role. The same will be true of most agents. Some will handle a slice of a human job. Some will cut across multiple jobs. Some will take on a bundle of responsibilities that only makes sense because software is not a human employee being paid for a nominal forty-hour week.

That does not weaken the metaphor. It just keeps it honest.

The point is not that agents are literally human employees. The point is that the employee frame produces better management instincts than the prompt frame does. It pushes you to think in terms of onboarding, trust, context, ownership, and escalation. It reminds you that what you are really building is not just output. You are building a system of collaboration.