Agent as Employee: Scoping Agent Needs

Introduction

Welcome to your second lesson in the "Mental Models for Agentic Systems" module. In our last session, we dissected the technical anatomy of an agent using the perception-reasoning-action-memory framework, grounding it in the formal structure of the CoALA paper. You learned to analyze any agentic system in terms of its core components: its memory modules, its internal and external action spaces, and its decision-making cycle.

Now that we have the universal technical blueprint, we need a complementary organizational mental model to bridge the gap between a client's business problem and your system design. This lesson introduces that bridge: the 'agent-as-employee' model.

Your learning outcome for this lesson is to apply the 'agent-as-employee' mental model to scope what an agent needs to know, do, and escalate. By treating an agent not as a tool but as a digital team member, you can systematically define its role, responsibilities, and boundaries, which in turn specifies the requirements for the technical architecture we've just discussed.

The 'Agent-as-Employee' Mental Model

The core idea is simple yet powerful: before you design any system, you first write the agent's "job description." This reframes the design process from "What can the tech do?" to "What does the business need done?" This approach is not just a useful analogy; it's a robust methodology for scoping and building reliable, effective agentic systems.

Let's begin by hearing this concept articulated by Harrison Chase, the creator of LangChain. He frequently uses the analogy of a "smart intern" to describe the current state of agent capabilities.

Thinking of an agent as an employee immediately forces us to ask three critical questions that form the backbone of a robust system specification:

1. What does it need to KNOW? (Its knowledge and context)
2. What does it need to DO? (Its responsibilities and capabilities)
3. When does it need to ESCALATE? (Its boundaries and a protocol for seeking help)

Let's break down each of these, mapping them back to the technical components you learned in the previous lesson.

1. What an Agent Needs to KNOW (Memory & Instructions)

Just like a human employee, an agent is ineffective without the right information. Scoping what an agent needs to "know" is the first step in designing its information environment. This maps directly to the Memory components of the CoALA framework and the concept of System Instructions.

We can categorize this knowledge into three types:

• Static Knowledge (The Employee Handbook): This is the core, unchanging information that defines the agent's identity and purpose. It includes its persona, role, rules of engagement, and policies it must follow. Architecturally, this is implemented as the system prompt or initial instructions.
• Dynamic Knowledge (The Company Intranet): This is external information the agent needs to access on-demand to perform its tasks, such as product specifications, customer histories, or policy documents. This corresponds to CoALA's Semantic Memory and is typically implemented using Retrieval-Augmented Generation (RAG).
• Experiential Knowledge (On-the-Job Learning): This is the memory of past interactions—what worked, what didn't, and user preferences. This corresponds to Episodic Memory. It allows the agent to maintain context within a conversation and, in more advanced systems, to learn and adapt over time.

2. What an Agent Needs to DO (Action Space)

An employee's value is defined by the tasks they perform. For an agent, this is its Action Space—the complete set of capabilities it can execute. Defining what an agent must "do" is the process of designing its tools and functions.

• Core Responsibilities (External Actions): These are the primary tasks the agent is "hired" to do, which involve interacting with the outside world. Each responsibility translates into a tool or an API call. For an "SDR Agent," its core responsibilities might be research_lead, check_crm, and draft_email. These are the grounding actions in the CoALA framework.
• Internal Processes (Internal Actions): These are the cognitive steps the agent takes to support its core responsibilities. This includes breaking down a problem, summarizing information, or reflecting on a past action before deciding on the next step. These map to the reasoning, retrieval, and learning actions in CoALA.

3. When an Agent Needs to ESCALATE (Decision Boundaries)

No employee has total autonomy, and neither should an agent. Defining escalation paths is critical for building safe, reliable systems that clients can trust. This process establishes the agent's decision-making boundaries and the all-important "human-in-the-loop" (HITL) workflows.

An agent should escalate when it encounters:

• Ambiguity: It lacks sufficient information or has low confidence in its next step.
• Out-of-Scope Requests: A user asks it to perform a task outside its defined responsibilities.
• Failed Actions: A tool call fails or returns an unexpected error.
• High-Stakes Decisions: It needs approval before taking an irreversible or costly action, such as sending a communication to a client, executing a financial transaction, or deleting data.

Let's return to the Harrison Chase video for a concrete example of this in practice with their SDR agent.

The SDR agent demonstrates the "Know, Do, Escalate" pattern perfectly:

• Knows: How to determine an interesting prospect (static knowledge/instructions).
• Does: Researches the prospect and drafts an email (external actions).
• Escalates: Puts the drafted email before a human for approval before sending (high-stakes decision gate).

This escalation mechanism is a core part of the agent's decision-making procedure, ensuring reliability and allowing for human oversight.

From Mental Model to Technical Specification

The 'agent-as-employee' model is not just a conceptual aid; it translates directly into a technical specification. A resource from Salesforce, which you can think of as an industrial-grade architectural guide, makes this connection explicit.

The Salesforce document provides a clean mapping from our mental model to their architecture:

This triad—Instructions, Actions, Guardrails—is a powerful and practical implementation of the Know, Do, Escalate framework.

Let's dive deeper into how this translates into a full design recipe. The Salesforce paper provides a detailed "Recipe" for an autonomous agent.

As you can see, defining an agent's "job" requires specifying its playbooks (what it knows how to do), decision criteria and scopes (what it is allowed to do), and fallback rules (how it escalates). This process transforms a business need into an actionable engineering plan.

A Holistic View: The Agent as Teammate

Thinking of an agent as an employee also forces us to consider its place within the broader organization. Will it be a solo contributor, or part of a team? This final resource provides practical advice for integrating agents into human workflows.

Starting with a clear role and job description isn't just good practice—it's the foundation of a successful agent deployment. It sets expectations for both the agent's performance and the human team's interaction with it.

Conclusion

In this lesson, we introduced the 'agent-as-employee' mental model as a powerful bridge between business requirements and technical design. By abstracting an agent into a role with a job description, we can systematically scope its functions and boundaries.

Key Takeaways:

• The 'agent-as-employee' model is a design methodology for scoping an agent's function within a business context.
• It forces you to define what the agent needs to KNOW (its memory and instructions), what it needs to DO (its action space and tools), and when it needs to ESCALATE (its boundaries and human-in-the-loop triggers).
• This framework maps directly to technical components: KNOW relates to System Instructions and Memory, DO relates to the Action Space, and ESCALATE relates to Guardrails and Decision-Making logic.
• Starting with a clear role and "job description" is the most effective way to ensure you build an agent that is reliable, safe, and delivers clear business value.

Preview of the Next Lesson:

Now that we have a model for defining an agent's "job," the next question is: what is the best way for the agent to think in order to perform that job? In the next lesson, we will explore different agent architectures, such as reactive vs. plan-and-execute agents. You will learn to select the optimal architecture based on the complexity of the "job description" you've defined, deciding whether your agent needs to be a simple checklist-follower or a strategic project manager.