# What Is Role Engineering? Managing AI Agents Like New Hires > Source: > Published: 2026-10-24 00:00:00+00:00 # What Is Role Engineering? Managing AI Agents Like New Hires Role engineering replaces prompt engineering: give AI agents goals, context, and examples like onboarding staff, not scripting instructions. ## What is role engineering? Role engineering is the practice of delegating goals to an AI agent the way a manager delegates to a new employee, rather than scripting exact instructions the way prompt engineering did. Instead of carefully wording a single request, you give the agent a specific, measurable goal, enough background context to act independently, and an example of good work, then let it run for extended periods while you check in periodically and give feedback. It treats the AI as a persistent collaborator with standing context, not a tool you re-prompt from scratch every time. ## TL;DR - **Role engineering replaces prompt engineering** as AI models become generalist enough to work from rough goals instead of precisely worded instructions. - **Anthropic’s own guidance recommends treating Claude “like a brilliant but new employee”** who needs context on norms and workflows, not perfect phrasing. - **SMART goals (specific, measurable, attainable, relevant, time-bound) are the delegation framework** , with measurability being the critical piece since it lets an agent verify its own work. - **Persistent knowledge bases replace manual context-building** , giving agents standing access to emails, transcripts, past AI sessions, and code repositories instead of requiring fresh context every session. - **Real examples from Anthropic staff show agents running autonomously for roughly two weeks** on tasks like rewriting a desktop app in a new language or building a compiler. - **Training an agent means running a task multiple times, comparing outputs, and compiling a list of fixes** , which effectively produces a reusable standard operating procedure. - **Cost management becomes a real constraint** , since long-running agent sessions can rack up thousands of dollars in token spend, making model selection and prompt caching practical necessities. ## One coffee. One working app. You bring the idea. Remy manages the project. ## How is role engineering different from prompt engineering? Prompt engineering focused on the exact wording of a request: the right phrasing, structure, and examples to coax a specific output from a model in a single exchange. It mattered because earlier models were brittle and literal. Role engineering assumes the opposite: that the model is capable enough to interpret a loosely specified goal correctly, the same way a competent employee can take a one-line instruction from a manager and fill in the details. The shift tracks a broader change in how AI is used inside organizations. Anthropic has said publicly that a large majority of the code it merges now comes through extended, largely autonomous agent sessions rather than turn-by-turn prompting. Employees give an agent a goal, let it run, and check back periodically rather than supervising every step. That pattern, goal in, autonomy during, review at checkpoints, is the core of what role engineering formalizes. ## How do you actually delegate a task to an AI agent? The practical framework borrows directly from decades of management practice: SMART goals. Specific, measurable, attainable, relevant, time-bound. Of these, measurability matters most for agents specifically. A vague instruction like “make my website better” gives an agent nothing to check its work against. A measurable version, like “get the homepage to load in under two seconds on a mobile display,” gives it a concrete target it can test itself. Without that, the agent can’t self-verify, which means it can’t know when it’s actually done. Background context is the second piece. Rather than re-explaining your goals, norms, and history every session, the emerging approach is to maintain a persistent knowledge base the agent can draw on: past conversations with AI tools, email, code repositories, documents, whatever constitutes the institutional memory of how you work. This removes the need to reconstruct context manually each time, which was the defining chore of “context engineering,” the intermediate step between prompt engineering and role engineering. The third piece is an example of the work done well. Models don’t have an innate sense of what “great” looks like for your specific goals. You have to show them, which in practice means doing the task yourself at least once, well, and handing that output over as the standard to match. ## What do real examples of this look like? The pattern shows up in how Anthropic’s own staff reportedly use Claude internally. One described instruction was to rewrite a desktop application originally built in Electron into Swift, with the agent told to run both versions, screenshot them, compare pixel by pixel, and keep iterating until they matched, a task that ran for roughly two weeks with periodic check-ins rather than constant supervision. Another example involved an agent joining a Slack thread unprompted and pulling together data from multiple tools into a single response from an instruction as casual as “can you make some designs, just mock it up.” A researcher reportedly had over a dozen Claude agents collaborate on building a C compiler with an instruction to “keep going until it’s perfect,” again running for about two weeks. What ties these together is the brevity of the instruction relative to the length and complexity of the task. None of these are detailed, engineered prompts. They’re goals stated the way you’d state them to a staff member you trust. ## How do you train an agent to get better over time? Running a task once isn’t enough to establish reliable quality. The recommended approach is to run the same task multiple times (five to ten repetitions is a reasonable range), review the outputs the way you’d review a new hire’s early work, and compile specific, itemized feedback: what was missing in one run, what went wrong in another, what should change going forward. That feedback gets fed back to the agent in a loop until the output consistently meets the bar. The output of this process is effectively a standard operating procedure, written down in a form that can be handed to any future agent or model version. That’s a meaningfully different artifact than a one-off prompt. It’s reusable institutional knowledge, and it compounds: every model upgrade benefits from the same accumulated SOP without needing to be re-taught from scratch. ## Is role engineering worth the cost? This is where the analogy to staffing gets literal rather than just useful shorthand. Long-running, high-autonomy agent sessions consume real money in token costs, and heavy usage can scale into tens of thousands of dollars a month for someone running agents as a primary part of their workflow. That makes cost auditing a practical necessity, not an afterthought. A few cost-management habits map directly onto how you’d manage a real team’s budget. Match model tier to task difficulty: cheaper, faster models for low-stakes or repetitive work, and the most capable (and expensive) models reserved for tasks that actually move the needle. Preserve prompt caching benefits by keeping related work sessions close together in time, since a second prompt within a caching window typically costs a fraction of a fresh one. Use batch processing for work that doesn’t need an immediate answer, since providers often price batched requests lower by routing them into idle compute capacity. And track total spend the way you’d involve finance before scaling headcount, rather than spinning up many parallel agents without a clear sense of what each one costs to run. For most individuals or small teams, a single well-configured agent handling the bulk of recurring work, with humans stepping in for review and edge cases, is a more sustainable starting point than running a large fleet of agents in parallel. ## Frequently Asked Questions ### What’s the difference between role engineering and context engineering? Context engineering refers to manually assembling the background information an agent needs for a given session. Role engineering goes further by maintaining persistent, standing context (through a knowledge base, for instance) so that reconstruction isn’t necessary each time, and by framing the entire interaction as ongoing delegation rather than a single well-prepared request. ### Why does “measurable” matter more than the other SMART criteria for AI agents? An agent can’t judge its own output without a way to check it against a target. A measurable goal gives it a verification mechanism, letting it iterate and self-correct. Goals that are only specific or relevant but not measurable leave the agent guessing at when it’s actually finished. ### Do you still need to write good prompts at all? Yes, but the emphasis shifts from precise wording to clear goals, context, and examples. A short, plainly stated instruction works fine if the agent has access to enough background and a quality benchmark to compare against. The engineering effort moves from the prompt itself to the surrounding scaffolding: goals, data access, and feedback loops. ### How long can AI agents realistically run unsupervised? Reported examples from people working closely with these tools describe agents running on a single task for roughly two weeks with periodic human check-ins rather than constant supervision, particularly for well-scoped, verifiable engineering tasks. Shorter check-in cycles are more common for less clearly defined or higher-stakes work. ### Does role engineering replace the need for human review? No. The practice still relies on humans reviewing outputs, giving corrective feedback, and deciding when an agent’s work meets the bar. The difference from manual prompting is the frequency and granularity of that review, closer to periodic management check-ins than turn-by-turn correction.