Three Terms, Three Different Jobs
Memory, tools, and guardrails are often mentioned in the same sentence in agent projects. Architecturally, however, they perform clearly separate jobs. Memory retains relevant state. Tools enable actions in other systems. Guardrails limit and check what may be read, written, or produced as output.
When these layers are mixed together, systems become difficult to maintain. A prompt suddenly serves as a data store, a tool decides its own permissions, and a post-processing text check is expected to catch every process error. A dependable harness keeps these responsibilities separate and connects them through an unambiguous workflow.
Memory: Remember What Matters, Not Everything
An agent needs short-term state for the current assignment and, where appropriate, long-term knowledge for later runs. These are not the same thing. Conversation history, the current work step, and temporary intermediate results belong in the runtime context. Confirmed rules, documented decisions, and approved facts belong in durable sources.
Good memory is therefore selective. It does not store arbitrary model wording as truth or retain personal data without a purpose. It records the origin, freshness, and validity of information. When a live system can provide the current status, that status takes precedence over an old memory.
- Short term: the assignment, current step, open questions, and temporary results
- Long term: confirmed rules, process knowledge, and approved decisions
- Canonical: files, CRM systems, databases, or APIs remain the source for facts that can change
Tools: Act with the Least Privilege Required
Tools turn a response into an action. That action might be a search, a CRM update, the creation of a file, or the sending of a message. This is precisely why every tool needs a narrow contract: permitted inputs, validated outputs, a time limit, defined error states, and minimal permissions.
An agent should not receive blanket access to an entire system when it only needs to create a single record. Read and write tools should be separated. Critical actions require idempotency keys or prior approval so that retries do not create duplicate bookings, send twice, or delete twice.
Guardrails: Boundaries Before, During, and After the Model
Guardrails are more than a sentence in the system prompt. Input limits protect against oversized or impermissible requests. Permission rules determine whether a tool may be used at all. Output schemas ensure that downstream systems receive structured data. Domain-specific checks verify that the result fits the process.
The Model Context Protocol separates host, client, and server, making it clear that security boundaries do not reside exclusively in the model. Among other things, the host controls permissions, context, and authorisation. This separation matters: a model can propose an action, but the harness decides whether it is permitted, confirmed, and actually executed.
How the Layers Work Together in a Quotation Process
An assignment arrives through a form or by email. Memory retains the customer mapping, processing status, and confirmed rules. Tools read product data, generate a document, and save a draft in the CRM. Guardrails check required fields, price limits, and recipients. Before the quotation is sent, the process stops for human approval. A tightly scoped tool then sends it exactly once and records the result.
None of these components alone would constitute the agent. Only their coordinated workflow makes the process reliable. The language model helps with understanding and creation; the harness ensures that this becomes controlled work.
Architecture Before Model Romanticism
Models improve and change faster than business processes. A cleanly separated harness therefore allows the model to be replaced without reinventing permissions, state, and security logic. This interchangeability is not merely technically elegant. It protects investments and prevents an entire process from depending on a single provider.