Building Your PoC: Agent Instructions and Mock Tools

Introduction

Welcome back. In our previous lesson, you designed the architecture for a minimal Proof-of-Concept (PoC), focusing on the "minimal viable path" to demonstrate core value to a client. We established the importance of the Supervisor orchestration pattern for control and traceability, and we decided to use a lean set of critical agents, tools, and data, relying on mock interfaces to manage complexity.

Now, we shift from blueprint to implementation. Today's lesson addresses the learning outcome: Implement the key components of a PoC, including simplified agent instructions and mock tool interfaces. This is where the architectural concepts become tangible code and configuration. We will translate your PoC design into a functional, albeit simplified, agentic workflow.

Given your background, we won't dwell on basic syntax. Instead, we'll focus on how to use a modern framework to implement the architectural patterns we've discussed. We'll see how defining agent behaviors and tool capabilities are the primary levers for a system designer, allowing you to construct complex workflows without getting lost in boilerplate code.

1. Implementing Agent Instructions: From Role to Prompt

The "instructions" for an agent are primarily implemented through its system prompt. A well-crafted system prompt is akin to a job description, a user manual, and a code of conduct all in one. For a PoC, your prompts should be simplified but precise, focusing on clearly defining each agent's role within the workflow.

Let's examine how to structure these prompts for a multi-agent PoC, specifically for an orchestrator and its specialist sub-agents.

The prompts in the video exemplify several critical principles for implementing agent instructions in a PoC:

• Define a Singular Role: The orchestrator's prompt is explicit: "You are a project orchestrator... You coordinate work, but you never implement anything yourself." This prevents the orchestrator from overstepping its bounds.
• Establish Clear Boundaries: The coder agent is told, "Question everything you're told. Make your own decisions." This is a crucial instruction to counteract the tendency of orchestrator models to be overly prescriptive, giving the specialist agent the autonomy it needs to perform its task correctly. This is a practical implementation of the principle of least authority we've discussed.
• Specify Collaboration Mechanisms: The orchestrator is explicitly told the names of the sub-agents it can delegate to: planner, coder, and designer. This defines its available "tools" at the agent level.

When implementing your PoC, you will write a simplified system prompt for each agent in your design (e.g., your Router and your Specialist). The prompt should contain:

1. Role: "You are a DocumentProcessingAgent."
2. Goal: "Your goal is to extract specific entities from a user-provided document."
3. Constraints: "You must only use the extract_entities tool. You do not answer questions or chat with the user."
4. Output Format: "Your final output must be a JSON object conforming to the following schema: {\"name\": \"...\", \"id_number\": \"...\"}."

This last point, enforcing structured output, is non-negotiable for reliable agentic systems, as it creates a stable contract for communication between agents.

2. Implementing Tool Interfaces: Mocking for Focus

In our PoC design, we decided to use mock interfaces for non-essential tools. A "tool" is simply a function that the agent can choose to execute. Implementing a mock tool involves two parts: the function itself, and a description that the LLM uses to understand its purpose.

Let's see how to bind a tool to an LLM and then apply that concept to create a mock interface.

As the video demonstrates, the core of tool implementation is surprisingly simple. The agent's model generates a structured request (e.g., a JSON object) specifying the tool to call and the arguments to use. Your application code then interprets this request, executes the corresponding function, and passes the result back to the agent.

Creating a Mock Tool

Now, let's apply this to our PoC strategy. Imagine your full workflow requires an agent to update a Salesforce record. A full implementation would involve API authentication, network requests, and error handling. For a PoC, this is unnecessary complexity.

Here’s how you would implement a mock tool for this action, for example, in Python:

# The tool's description is crucial for the LLM to know when to use it.
# This would be provided to the agent as part of its available tools.
tool_description = {
    "name": "update_salesforce_record",
    "description": "Updates a customer record in Salesforce with new information.",
    "parameters": {
        "type": "object",
        "properties": {
            "record_id": {"type": "string", "description": "The ID of the Salesforce record to update."},
            "new_data": {"type": "object", "description": "A JSON object containing the fields to update."}
        },
        "required": ["record_id", "new_data"]
    }
}




# The mock function itself. It doesn't connect to Salesforce.
def update_salesforce_record(record_id: str, new_data: dict) -> dict:
    """Mock function to simulate updating a Salesforce record."""
    print(f"[MOCK] Updating Salesforce record {record_id} with data: {new_data}")



    # In a PoC, always return a success message to allow the workflow to proceed.
    return {"status": "success", "record_id": record_id}

By implementing your non-critical tools this way, you isolate the agent's reasoning and decision-making capabilities—the very thing you want to test—from the engineering overhead of external integrations.

3. Assembling the PoC Workflow with LangGraph

With agent instructions written and mock tools defined, you can now assemble the workflow. A framework like LangGraph is ideal for this, as it allows you to define your agentic workflow as a state graph. This maps directly to the architectural diagrams you've designed and should be conceptually familiar from your computer science background.

• Nodes: These are the actors in your workflow. A node can be an agent (an LLM call with specific instructions) or a tool (a function call).
• Edges: These define the control flow, directing the output of one node to the input of another. Conditional edges allow for routing and decision-making.
• State: A shared object that is passed between nodes, allowing them to read and write information as the workflow progresses.

The following resource walks through implementing various agentic patterns using this graph-based approach.

As you can see, implementing your PoC architecture in a framework like LangGraph is less about writing low-level control flow and more about architecting a graph:

1. Define your state object: What information needs to be tracked? (e.g., user query, intermediate results, final answer).
2. Implement your nodes: Write Python functions for each agent and tool. The "agent" function will encapsulate the LLM call with its specific system prompt. The "tool" function will be your mock implementation.
3. Wire your graph: Define the edges that connect the nodes, implementing the logic of your Supervisor pattern.

This approach keeps your implementation clean, modular, and directly reflective of your high-level design, which is essential for both debugging and for eventually handing the system off to a client.

Conclusion

In this lesson, you have learned how to take a PoC design and implement its core components. We've moved from the "what" to the "how," focusing on the key levers you have as a system designer: agent instructions and tool interfaces.

Key Takeaways:

• Agent Instructions as Prompts: Implement agent behavior through clear, role-focused system prompts that define responsibilities, boundaries, and output formats.
• Mock Tools as Functions: Create mock tool interfaces by writing simple functions with clear, LLM-readable descriptions. These functions should return predictable success responses to allow for focused testing of agent logic.
• Workflows as Graphs: Use frameworks like LangGraph to implement orchestration patterns by defining agents and tools as nodes and control flow as edges. This aligns implementation directly with your architectural design.

You have now designed a PoC and implemented its fundamental components. However, a working prototype is not enough; you need to prove it delivers on its core promise. In our next lesson, you will learn how to test the PoC against representative examples to validate core functionality for a client demonstration. We will cover how to create evaluation data, define success metrics, and gather the evidence you need to move forward with confidence.