TechByteByByte

The Agent Mental Model

Mapping Module 2's precise definition onto a complete set of concepts — goal, environment, state, observation, action, decision, tool, context, feedback — anchored by a human-employee analogy used throughout this course.

#AI Agents#AI#Mental Model#Level 1

Begin with the problem

Before code, an agent needs a map: goal, environment, observations, state, decisions, actions, and a stopping rule.

goal + context + state + memory → decision → action → observation → updated context

What you will learn

  • Visualize an agent as a worker with a goal, workspace, tools, notebook, and supervisor.
  • Separate goal, context, state, memory, action, and observation.
  • Follow how one decision changes the information available for the next decision.
  • Use the mental model to explain unfamiliar agent architectures.

Current real-system grounding: Google’s current Agents overview documents managed agent harnesses with tools, loops, context management, sandboxed execution, and multi-step research.

These official links document available product features. They do not reveal every provider’s private implementation, hidden reasoning, default setting, or internal limit.

1. The problem this module solves

Module 2 defined an Agent precisely, but a single definition doesn’t yet give you the full working vocabulary this course needs. This module builds that vocabulary — goal, environment, state, observation, action, decision, tool, context, feedback — anchored by a single, consistent real-world analogy you can return to whenever a new concept feels abstract.

2. The Anchor Analogy — A Human Employee

Imagine a new customer support employee, on their first day, handling a single ticket:

GOAL:      "Resolve this customer's complaint about a late order."

ENVIRONMENT:      the order management system, the shipping carrier's
                 website, their email client -- everything they can
                 interact with or observe

INFORMATION (Observation):      checking the order status, reading
                               the customer's message

DECISION:                           "Since the order is late, I
                                   should check the shipping carrier's
                                   tracking page next."

ACTION:                                 actually opening the tracking
                                      page and looking up the package

FEEDBACK (new observation):                 "The package shows as
                                          delivered 2 days ago,
                                          despite the customer saying
                                          they never received it."

NEXT DECISION:                                  "I should check if
                                              someone else at their
                                              address may have
                                              received it, or escalate
                                              to a claims process."

Every single concept this module covers maps directly onto this one scenario — hold onto it.

3. Mapping Each Concept to an AI Agent

Human Employee ConceptAI Agent ConceptWhat It Means
The task they were asked to completeGoalThe explicit outcome the agent is pursuing
Everything they can look at or interact withEnvironmentSystems, APIs, files, data the agent can observe or act on
What they currently know about the situationStateThe agent’s evolving, internal understanding as the task progresses (Module 12 covers this deeply)
Checking the order status pageObservationNew information the agent perceives from the environment
“I should check the tracking page next”Decision / ReasoningThe LLM’s real reasoning about what to do given the current state
Actually opening the tracking pageActionA concrete step the agent takes — often via a tool (Module 6)
“The package was delivered”FeedbackThe result of an action, which becomes the next observation
Their notepad, ticket history, prior contextContextEverything available to inform the current decision

4. The Complete Flow

flowchart TD
    U[User Request] --> G[Goal]
    G --> Ag[Agent]
    Ag --> O[Observe]
    O --> R[Reason]
    R --> Ac[Act]
    Ac --> OR[Observe Result]
    OR --> R
    R --> Done[Goal Completed]

This is the same loop from Module 1, Section 7 and Module 2, Section 3 — this module’s contribution is naming every individual PIECE of that loop precisely, so later modules can discuss them independently.

5. Goal vs. Environment vs. State — A Important

Distinction

GOAL:      WHAT the agent is trying to achieve -- fixed for the
         duration of the task (though Module 8 covers how a goal
         can be DECOMPOSED into sub-goals)

ENVIRONMENT:      everything the agent CAN potentially observe or
                 act upon -- broader than what it HAS
                 observed so far

STATE:                what the agent CURRENTLY KNOWS -- its evolving,
                     internal understanding, built up from what it
                     has ACTUALLY observed and done so far (Module 11
                     covers this precisely)

A useful way to keep these separate: the environment is like the entire building the employee works in — full of information they could access. Their state is like their own personal notes at this specific moment — only what they’ve actually looked at and learned so far. The goal never changes mid-task, while the state grows and updates with every new observation.

6. Observation and Action — Two Directions of Interaction

OBSERVATION:      information flowing FROM the environment TO the
                 agent (Environment -> Agent)

ACTION:               the agent doing something TO the environment
                     (Agent -> Environment)

These are the two directions of the agent’s interaction with the world — and the loop from Section 4 is precisely the alternation between them: observe, act, observe the result of that action, act again.

7. Decision and Context — Where the LLM Sits

DECISION:      the OUTPUT of reasoning -- "what should I do next?"

CONTEXT:           everything the LLM is given to REASON
                 WITH when making that decision -- the goal, the
                 current state, the most recent observation, and
                 (Module 11) whatever memory is relevant

This directly connects to your Prompt Engineering course: the quality of an agent’s decisions is bounded by the quality of the context it’s given. An agent reasoning without the right context in front of it can only make decisions as good as its training knowledge alone allows — exactly your Generative AI course’s hallucination discussion, now applied to agent decision-making specifically.

8. A Real Developer Example

TechCorp’s late-order agent, walked through this module’s complete vocabulary:

StepConceptWhat Happens
1Goal“Resolve this customer’s complaint about a late order.”
2EnvironmentOrder system, shipping carrier API, email client — all available, none yet observed
3ObservationAgent checks order status: “Order #4471, marked LATE”
4State updateAgent’s internal understanding now includes: order is late
5DecisionGiven goal + state, reason: “I should check the shipping carrier next.”
6ActionCall the shipping carrier’s tracking tool
7Feedback / New Observation“Package shows delivered 2 days ago”
8State updateUnderstanding now includes: carrier claims delivery, but customer disputes it
9Decision (again)“This needs a claims escalation, not a simple reply.”
10Goal completedEscalation ticket created, customer notified

9. A Simple Agentic AI Connection

This entire module is the agentic connection — every future module builds directly on this vocabulary. When Module 4 covers loop mechanics, Module 6 covers tools, and Module 11 covers memory, you’ll be adding depth to concepts already named here, not learning disconnected new ideas.

10. How Is This Used in AI?

🤖 How Is This Used in AI?

This precise vocabulary is how production agent systems are designed and discussed — separating “what’s the goal,” “what can the agent observe,” “what does it currently know (state),” and “what context does it reason with” makes agent behavior debuggable and explainable, directly connecting to Module 20’s observability discussion later in this course.

11. Real-World Applications

  • Designing an agent’s system prompt (defining its goal and available environment clearly)
  • Debugging unexpected agent behavior by isolating exactly which concept — observation, state, context, or decision — went wrong
  • Technical design documents and architecture reviews for agentic systems

12. Common Mistakes

Incorrect idea: Conflating environment with state.

Why it is incorrect: As shown directly in Section 5, the environment is everything POTENTIALLY available; state is what the agent has ACTUALLY learned so far — different concepts.

Incorrect idea: Assuming the agent’s context automatically includes everything relevant.

Why it is incorrect: As shown directly in Section 7, context is only what’s given to the LLM — missing context produces worse decisions, exactly like an employee missing key information.

Incorrect idea: Treating “goal” as something that can silently change mid-task.

Why it is incorrect: As shown directly in Section 5, the goal is fixed for the task’s duration — Module 8 covers deliberate goal DECOMPOSITION into sub-goals, which is different from the goal itself shifting.

13. Limitations

  • This mental model is a real simplification for teaching clarity — real agent implementations sometimes blend these concepts in ways that don’t map perfectly cleanly onto this vocabulary
  • The human-employee analogy, while useful, breaks down at the edges (a human has real judgment and accountability an agent doesn’t) — Module 15’s human-in-the-loop discussion addresses this directly

14. Quick Reference

flowchart LR
    subgraph Environment
        E1[Order System]
        E2[Shipping API]
        E3[Email Client]
    end
    Environment -->|Observation| State[Agent State<br/>current understanding]
    Goal[Fixed Goal] --> Decision{Reason /<br/>Decide}
    State --> Decision
    Context[Context: goal + state<br/>+ observation + memory] --> Decision
    Decision --> Action[Action]
    Action -->|affects| Environment

15. Code — Implementing the Complete Mental Model

🎯 Target of this example: implement Section 8’s real developer example directly — separate goal, environment, state, observation, and decision as distinct, explicit concepts in code, exactly this module’s vocabulary made concrete.

Example 1 — Simple

from dataclasses import dataclass, field

@dataclass
class AgentComponents:
    """Mirrors the human-employee analogy directly onto agent
    components -- goal, environment, and state as separate
    concepts, per Section 5's distinction."""
    goal: str
    environment: dict
    state: dict = field(default_factory=dict)

def observe(agent: AgentComponents) -> str:
    """The agent 'looks' at its environment -- exactly a human
    employee checking a dashboard (Section 6: environment -> agent)."""
    return agent.environment.get("current_status", "nothing new")

def decide(agent: AgentComponents, observation: str) -> str:
    """Reasoning: given the CONTEXT (goal + current state +
    observation), what should happen next? (Section 7)"""
    if "late" in observation.lower():
        return "check_shipping_carrier"
    if "delivered" in observation.lower():
        return "close_ticket"
    return "wait"

agent = AgentComponents(
    goal="Resolve customer's late-order complaint",
    environment={"current_status": "Order is marked LATE"},
)

observation = observe(agent)
decision = decide(agent, observation)

print(f"Goal: {agent.goal}")
print(f"Observation: {observation}")
print(f"Decision: {decision}")

Expected Output:

Goal: Resolve customer's late-order complaint
Observation: Order is marked LATE
Decision: check_shipping_carrier

What we conclude from this example: goal, environment, and the observation derived from it are separate, explicit values in this code — exactly Section 5’s distinction, not blended together into one undifferentiated blob of “agent stuff.”

Example 2 — Intermediate

from dataclasses import dataclass, field

@dataclass
class AgentComponents:
    goal: str
    environment: dict
    state: dict = field(default_factory=dict)

def observe(agent: AgentComponents, source: str) -> str:
    return agent.environment.get(source, "nothing new")

def update_state(agent: AgentComponents, key: str, value: str) -> None:
    """Directly implements Section 5's claim: state GROWS and UPDATES
    with every new observation, distinct from the fixed
    goal and the broader, mostly-unobserved environment."""
    agent.state[key] = value

def decide(agent: AgentComponents) -> str:
    """Reasoning now uses the FULL context -- goal AND accumulated
    state -- not just the most recent observation alone (Section 7)."""
    if agent.state.get("order_status") == "late" and "carrier_status" not in agent.state:
        return "check_shipping_carrier"
    if agent.state.get("carrier_status") == "delivered" and agent.state.get("customer_disputes") == "true":
        return "escalate_to_claims"
    return "wait"

agent = AgentComponents(
    goal="Resolve customer's late-order complaint",
    environment={
        "order_system": "Order is marked LATE",
        "shipping_api": "Package shows DELIVERED 2 days ago",
        "customer_message": "I never received my package",
    },
)

# Step 1: observe order status, update state, decide
order_obs = observe(agent, "order_system")
update_state(agent, "order_status", "late")
print(f"Step 1 -- observed: '{order_obs}' -> decision: {decide(agent)}")

# Step 2: observe shipping carrier, update state, decide again
carrier_obs = observe(agent, "shipping_api")
update_state(agent, "carrier_status", "delivered")
update_state(agent, "customer_disputes", "true")
print(f"Step 2 -- observed: '{carrier_obs}' -> decision: {decide(agent)}")

print(f"\nFinal accumulated state: {agent.state}")

Expected Output:

Step 1 -- observed: 'Order is marked LATE' -> decision:
check_shipping_carrier
Step 2 -- observed: 'Package shows DELIVERED 2 days ago' -> decision:
escalate_to_claims

Final accumulated state: {'order_status': 'late', 'carrier_status':
'delivered', 'customer_disputes': 'true'}

What we conclude from this example: agent.state GROWS across two steps — starting empty, then accumulating order_status, then carrier_status and customer_disputes — while agent.goal never changes and agent.environment remains the same, fixed set of available sources throughout. This directly demonstrates Section 5’s distinction as real, observable code behavior, exactly tracing Section 8’s ten-step TechCorp walkthrough.

Example 3 — Production Grade

from dataclasses import dataclass, field
from datetime import datetime

@dataclass
class ObservationRecord:
    source: str
    content: str
    timestamp: str

@dataclass
class ProductionAgent:
    """A production-style implementation making EVERY concept from
    this module's vocabulary an EXPLICIT, separately-inspectable
    attribute -- directly supporting Section 10's observability
    connection, since each concept can be logged and audited
    independently."""
    goal: str
    environment: dict
    state: dict = field(default_factory=dict)
    observation_history: list = field(default_factory=list)
    decision_history: list = field(default_factory=list)

    def observe(self, source: str) -> str:
        content = self.environment.get(source, "nothing new")
        self.observation_history.append(
            ObservationRecord(source=source, content=content, timestamp=datetime.now().isoformat())
        )
        return content

    def update_state(self, key: str, value: str) -> None:
        self.state[key] = value

    def decide(self) -> str:
        if self.state.get("order_status") == "late" and "carrier_status" not in self.state:
            decision = "check_shipping_carrier"
        elif self.state.get("carrier_status") == "delivered" and self.state.get("customer_disputes") == "true":
            decision = "escalate_to_claims"
        else:
            decision = "wait"
        self.decision_history.append(decision)
        return decision

    def is_goal_achieved(self) -> bool:
        return self.decision_history and self.decision_history[-1] == "escalate_to_claims"

agent = ProductionAgent(
    goal="Resolve customer's late-order complaint",
    environment={
        "order_system": "Order is marked LATE",
        "shipping_api": "Package shows DELIVERED 2 days ago",
    },
)

agent.observe("order_system")
agent.update_state("order_status", "late")
agent.decide()

agent.observe("shipping_api")
agent.update_state("carrier_status", "delivered")
agent.update_state("customer_disputes", "true")
agent.decide()

print(f"Goal achieved: {agent.is_goal_achieved()}")
print(f"Total observations made: {len(agent.observation_history)}")
print(f"Decision history: {agent.decision_history}")

Expected Output:

Goal achieved: True
Total observations made: 2
Decision history: ['check_shipping_carrier', 'escalate_to_claims']

What we conclude from this example: tracking observation_history and decision_history as explicit, separate logs (rather than overwriting values in place) makes the agent’s ENTIRE reasoning trajectory inspectable after the fact — exactly the foundation Module 20’s observability discussion builds on, and a direct, practical payoff of taking this module’s vocabulary seriously as distinct, loggable concepts rather than one undifferentiated “agent state” blob.

16. Interview Questions

Q: Using the human-employee analogy, explain the difference between an agent’s environment and its state.

Ans: The environment is everything the agent could potentially observe or act upon — like the entire building an employee works in, full of information they could access but haven’t necessarily looked at yet. The state is what the agent currently, actually knows — like the employee’s own notes at a specific moment, built up only from what they’ve actually observed and done so far. The environment stays broadly the same throughout a task; the state grows and updates with every new observation.

Q: How does context relate to the quality of an agent’s decisions?

Ans: Context is everything the LLM is actually given to reason with when making a decision — the goal, the current state, the most recent observation, and relevant memory. An agent’s decision quality is bounded by the quality and completeness of this context — an agent reasoning without the right information in front of it can only make decisions as good as its general training knowledge allows, directly echoing the hallucination risk covered in earlier courses, now applied specifically to an agent’s decision-making at each step of its loop.

Q: Why is it important to keep “goal” distinct from “state” in an agent’s design, rather than letting them blend together?

Ans: The goal represents what the agent is fixedly trying to achieve for the duration of a task, while state represents the agent’s evolving understanding as it progresses. If these blend together without clear separation, it becomes difficult to reason about whether an agent is failing because its goal was poorly defined versus because its state tracking or reasoning about that state is flawed — keeping them conceptually distinct supports precise debugging, directly connecting to later modules on failure diagnosis.

Q: Design a simple monitoring approach for an agent using this module’s vocabulary — what would you specifically want to log at each step, and why?

Ans: I’d log each observation (source and content) separately from each decision, along with the state at the time each decision was made — rather than only logging the final output. This lets you reconstruct the agent’s complete reasoning trajectory after the fact: what it actually observed, how its understanding (state) evolved, and what it decided at each point given that evolving understanding — directly enabling the kind of diagnostic process needed when an agent produces an unexpected or incorrect final result.

17. What You Should Remember

  • The human-employee analogy — goal, environment, state, observation, decision, action, feedback, context — anchors every concept this course will build on.
  • Environment, state, and goal are distinct — verified directly by observing state accumulate across steps while goal and environment remain fixed.
  • Context is what the LLM is actually given to reason with, and bounds decision quality — logging observations and decisions separately (verified directly in a production-style implementation) supports real debuggability.

18. Quick Practice

Pick a multi-step task you’ve done recently (planning a trip, debugging a piece of code, researching a purchase). Walk through this module’s complete vocabulary — goal, environment, observations, state, decisions, actions, feedback — mapping each concept onto your own actual process.

19. Next Step

Next: Module 4 — The Agent Loop Deep Dive — Level 2 begins here: the mechanics of how this loop actually runs, terminates, handles failures, and avoids getting stuck.

Author
TechByteByByte Editorial Team
Reviewed by
TechByteByByte Admin
Published
Last reviewed