AI agents, defined: goal, tools, loop and memory

"AI agent" now gets attached to everything from a chat window with a search button to a fully automated back-office process. That makes it hard to decide what you can trust one with. This page gives a definition you can use in practice: what an agent is made of, how it differs from a chatbot and from a scripted workflow, and which properties make it reasonable to hand one real work.

A working definition

An AI agent is software that pursues a goal by deciding its own next step, using tools to act, observing the result, and repeating until the goal is met or a limit is reached. Four parts carry that definition.

1. Goal. An outcome with a recognizable end state, not a topic. "Research our suppliers" is a topic. "List every supplier contract that renews automatically next quarter, with the clause that says so" is a goal, because you can tell when it is done.
2. Tools. The functions the agent may call: search a document set, read a file, query a database, draft an email, open a page in a browser. Tools are where the agent touches the world, so they are where both its usefulness and its risk live.
3. Loop. Plan, act, observe, adjust. The agent chooses a tool, reads what came back and decides what to do next. A chatbot answers once; an agent keeps going.
4. Memory. What the agent carries between steps (the working context of this run) and, optionally, what it keeps between runs (preferences, facts about a project, earlier results).

Take away any one of the four and you have something else: without a goal it is a chat, without tools a text generator, without a loop a single function call, and without memory an agent that has to work out the same facts again at every step.

The loop in practice

Most of what is interesting about an agent happens inside the loop. The trace of a single run usually looks something like this:

goal     supplier contracts that renew automatically next quarter
plan     list files in /contracts, read each one, extract renewal terms
tool     list_files("/contracts")            -> 14 files
tool     read_file("supplier-a.pdf")         -> renewal clause on page 7
observe  renews automatically, 60-day notice period
tool     read_file("supplier-b.pdf")         -> no renewal clause found
observe  record as "unknown", note the pages checked
...
check    every file has a row or an explicit "unknown"
stop     acceptance criteria met

Three things in that trace matter more than the model behind it. First, the agent decided which tool to call at each step; nobody scripted the order. Second, it recorded a missing clause as unknown instead of guessing. Third, it stopped for a stated reason.

A well-built loop has several ways to stop, and each one should be visible: the goal is met; the agent is stuck and says so; a limit is reached (time, number of tool calls, spend); or the next step needs a person's decision. An agent that can only stop by "finishing" will eventually finish by inventing something.

Agents, chatbots and workflows

The three are easy to confuse because they can share the same model and even the same interface. The real difference is who decides what happens next.

In real systems they blend. A common and sensible design is a fixed workflow with agent steps inside it: the order is scripted, but "read these filings and pull out the risk factors" is delegated to an agent. The guide to agentic workflows covers where each approach fits. A rough rule: if you can write the steps down in advance and they rarely change, script them. Use an agent where the next step genuinely depends on what the previous one found.

The model is not the agent

A language model on its own predicts text. It becomes an agent only when something around it supplies the goal, exposes the tools, runs the loop, stores memory and enforces limits. That surrounding software is usually called the agent harness, and in practice it decides most of what the agent can and cannot do.

This has a practical consequence for anyone evaluating agents: the same model can be safe in one harness and reckless in another. Questions such as "can it delete files?", "who sees what it did?" and "what stops it?" are answered by the harness, not by the model. Tool access is increasingly standardized through protocols such as MCP, which makes connecting a tool easy. A protocol does not decide whether a particular task should be allowed to use that tool.

Memory: useful, and easy to get wrong

Within a run, memory is simply the context the agent works from: the goal, what it has read, what it has tried. Across runs, memory becomes a store of facts and preferences, and that is where problems start. A stale fact gets reused as if it were current. A one-off remark in a chat ("we never discount for this segment") turns into a standing rule nobody approved. Something learned in one project surfaces in another where it does not belong.

Three habits keep long-term memory honest. Scope each memory as narrowly as you can: one session, one user, one project, or the whole company. Treat a new memory as a proposal with a source and a reason, and let a person approve it before it counts. And when a fact changes, write a new version instead of silently overwriting the old one. Memory is also not a live feed; when an answer depends on current facts, the agent should go back to the source. Memory with consent looks at the approval side in more detail.

What makes an agent safe to delegate to

Capability is the easy part of the evaluation. The harder question is whether you could hand the agent a piece of work, walk away, and later understand exactly what happened. In practice that comes down to six properties.

1. A written goal with acceptance criteria. Done is defined before the agent starts, in terms a reviewer can check. See write acceptance criteria first.
2. A bounded scope. The documents, systems and tools the work may touch are named. Start read-only and widen deliberately.
3. Hard limits. Wall-clock time, number of tool calls and spend, each enforced rather than suggested.
4. A pause before consequential actions. Sending something out, deleting, exporting data, scheduling recurring work, acting in a live session, changing its own instructions and handing work to another agent should all wait for a person.
5. Evidence attached to claims. Every finding points to the passage or record it came from, and missing information stays marked as missing.
6. A visible trail and a stop control. Every request, tool call, decision and outcome is recorded where the team can read it, and one control halts the work.

Here is what a checkable acceptance criterion looks like, as opposed to "do a thorough job":

Every contract in the folder appears in the output table exactly once. Each renewal date cites the page and clause it came from. Contracts without a renewal clause are listed as "no clause found" with the pages searched. No contract is summarized from memory or from its file name.

How GoCux applies these properties

GoCux is a company workspace built around that list. Work starts as a work order: a goal, the scope the work may touch, and the acceptance criteria that define done. GoCux picks the skills the work needs, and the order moves through four visible states: queued, running, awaiting decision and done. The third state is the gate. When the work reaches one of seven consequential action classes, such as sending something out or exporting data, it stops and waits for someone on the team, and nothing downstream starts until they decide. Routine steps inside the limits you set run without interrupting anyone.

Each step lands on the work order's record as it happens, so the result, its sources and every decision sit together. Work draws on visible credits under a daily cap and stops, with an explanation, at the ceiling; a single stop control halts new work across the installation. Memory follows the same logic: a proposed memory stays separate from an approved one until someone accepts it. The Task page shows the work order itself, governance describes the gate and the trail, and the seven action classes are explained one by one in a separate note.

Before you hand an agent real work

Use this as a short pre-flight check, whichever product you use.

• Can you state the goal in one sentence with a clear end state?
• Have you written acceptance criteria a colleague could check without asking you?
• Is the tool list as short as the work allows, and read-only wherever possible?
• Are time, tool-call and spend limits set, and do you know what happens when one is hit?
• Which actions will pause for a person, and who is allowed to approve them?
• Will each finding carry its source, and will gaps be reported as gaps?
• Can you read the full trail of a run afterwards, including rejected steps?
• Do you know where the stop control is, and who may resume work after it is used?

If several answers are "not sure", the agent may still be useful for drafts and research, but it is not ready for work that leaves the building.