The guide

The concepts, step by step

Eight short sections. Each one explains a single idea in plain language and shows where it appears in the working agent on the next page. You do not need any agent background to follow along.

Model thinks. Tool does. Agent decides. Harness controls.

Concept 1

Model

A model is the reasoning engine. It reads input and generates a response or decision.

A model like Llama or Claude takes text in and produces text out. That is all it does. It cannot look up your leave balance, query a database, or send an email. It can only read and write text. This lab uses a Llama model running on Groq, but the idea is the same for any model.

Keep this in mind for everything that follows: a model is not an agent by itself.

Concept 2

Tool

A tool is a function or API the model is allowed to request.

A tool is ordinary code. In this lab, one tool looks up an employee's remaining leave days in sample data, and a second tool returns the company leave policy. The model never runs the code itself. It can only ask for a tool to be run. The system around the model executes it and hands the result back.

A tool is just a function

function lookupLeaveBalance(employeeName) {
  // reads from sample data, returns e.g.
  // { found: true, employeeName: "Rupesh", remainingDays: 12 }
}

The tool reads data and returns a structured result. The model decides when it should be called.

Concept 3

Tool definition

A tool definition tells the model the tool's name, purpose, inputs, and output shape.

The model never sees your code. It only sees a short contract: the tool's name, a description of when to use it, and what inputs it needs. Writing this contract clearly is most of the work. A vague description leads to the model calling the wrong tool or no tool at all.

The contract the model sees

{
  name: "get_leave_balance",
  description: "Use this tool only when the user asks for the
    remaining leave balance of a named employee.",
  input: { employeeName: "string" }
}

The description tells the model when to use the tool. The input schema tells it exactly what to provide.

Concept 4

Agent

An agent is a model operating in a loop with instructions and tools to complete a goal.

Put the pieces together and you get an agent. The instructions say what the assistant is for and what it must not do. The tools give it controlled access to data. The loop lets it take more than one step before answering.

Agent = Model + Instructions + Tools + Loop

Concept 5

Agent loop

The loop is the sequence the agent repeats: read, decide, act, observe. It runs until the agent can answer.

1User asks a question
2Model reads the question
3Model chooses a tool
4Tool receives an input
5Tool returns data
6Model uses the result
7Agent gives the final answer

Some questions need one pass through the loop, some need several. Ask the demo agent “Can Rupesh take six days of leave?” and it will check the balance, then fetch the policy, then combine both results into one answer. That is three model decisions in a single run.

Concept 6

Memory

Memory lets an agent use earlier conversation context. It does not automatically mean permanent storage.

In this lab, memory is simply the conversation so far, sent along with each new question. That is why you can ask “How many leave days does Rupesh have?” and then follow up with “What about Maria?”. The agent reads the earlier exchange and understands the new question is also about leave balances.

This is short-term memory. It lasts for one page session and is gone when you reset or reload. Long-term memory across sessions is a separate design decision, and this lab leaves it out on purpose.

Concept 7

Harness

The harness is everything around the model: which tools exist, how the loop runs, when it stops, how errors are handled, and what is logged. In enterprise systems, reliability comes from the harness, not the model alone.

The demo agent's harness enforces real limits: at most five model invocations and four tool executions per run, a 30-second timeout, input validation, rate limits on the public endpoint, and structured errors instead of raw stack traces. The model never gets a tool that was not explicitly registered. There is no internet search and no way to invent one.

When people say an agent is “enterprise-ready”, they are mostly describing the harness.

Concept 8

How code maps to concepts

Every concept above corresponds to one visible piece of the code.

Mapping of code elements to agent concepts
Code	Concept
model	reasoning engine
tools	permitted actions
system prompt	instructions and boundaries
createAgent	assembles the loop
invoke	starts one run
messages	conversation context
step limits	harness stopping conditions

The whole agent, assembled

const agent = createAgent({
  model,                                // reasoning engine
  tools: [getLeaveBalance, getLeavePolicy], // permitted actions
  systemPrompt,                         // instructions and boundaries
});

await agent.invoke({ messages });       // one run of the loop

This is real code from the demo (LangChain JS). The harness adds step limits, a timeout, and rate limiting around this call.

Where this goes next

The two tools in this lab read sample data. In a real deployment, the same pattern connects to SAP, Workday, ServiceNow, Salesforce, a database, or an MCP server. The tool definition stays the contract the model sees. Only the code behind it changes. You swap the plumbing without retraining anything. This lab stops before those integrations so the pattern itself stays easy to see.

Now try the agent Back to start