ABS Chat with Skills and Memory: A Practical Scoping Guide

Start with the full context model

A useful chat session is not just a prompt sent to a model. It is a prompt plus the operating context that helps the agent interpret the request and act safely. In ABS, that context can include skills, memory, and the fact store.

• Skills are procedural instructions: how to perform a recurring task, which commands to use, and what pitfalls to avoid.
• Memory is durable context about the user, projects, decisions, and working preferences.
• The fact store is the structured layer for stable, retrievable facts rather than a long narrative of past conversations.

The default mode is intentionally broad. It is designed to make a general chat session useful without requiring the user to know which skill, memory entry, or tool is relevant before asking the question. That convenience has a cost: the agent may load more context and expose more capabilities than a narrowly defined task needs.

Think of default mode as a well-equipped workbench. It is the right starting point when the request is ambiguous, spans several domains, or depends on context you do not yet know how to name.

A deliberately scoped session

When you already know the job, you can make the operating envelope explicit. For example:

hermes chat \
  --skills abs,image-gen \
  --toolsets terminal,web \
  --provider anthropic

This says: bring in the ABS skill and the image-generation skill; make terminal and web tools available; and use the Anthropic provider for this run.

The important distinction is between context and capability. The skills explain how to work. The toolsets determine which classes of action are available. Memory and fact_store still matter because a scoped session should not become amnesiac: narrowing the operational surface is not the same as throwing away relevant project history.

A practical request might be: “Use the ABS content conventions, check the current documentation on the web, and generate a header image.” The example flags cover exactly that shape. They avoid loading unrelated development, email, media, or infrastructure procedures while preserving the relevant instructions and knowledge.

Why default loads everything

Broad loading is a product decision, not an accident. Before a user has classified a request, the agent cannot reliably know whether it will need a browser, a shell, a writing skill, or a project-specific memory. Loading the available context up front reduces the number of turns spent discovering missing capabilities and makes mixed requests feel seamless.

It also supports questions that change shape as they are answered. A request that begins as “help me write this post” may become “check the source,” “render an image,” or “patch the site.” Default mode keeps those transitions possible.

The trade-off, of course, is per-call cost: every tool added to a session costs a few hundred tokens of context, multiplied by every model turn. Scoping is the lever to pull when the cost outweighs the seamlessness.

The trade-off is that more context can dilute the signal from the task at hand. Broad instructions may compete for attention, and broad tool availability increases the number of possible paths. Default is therefore a sensible general mode, not a commandment that every session should use the maximum context.

The three cases for scoping down

1. Cost

Context consumes tokens. Skills, memories, and tool descriptions all contribute to the material the provider must process. If a task is repetitive and well understood, sending only the relevant pieces can reduce input usage and make provider spend more predictable.

Cost matters most for batch work, frequent editorial runs, and long conversations where the accumulated context would otherwise be repeatedly carried forward. Scope by task, not by habit: keep the skills and facts that affect the result, and omit unrelated domains.

2. Latency

A smaller context gives the provider less to read and the agent less to organize before it responds. That can shorten time to first useful output, especially when a session also uses web or terminal tools.

Latency is the practical reason to scope a quick operation. If the job is “look up one current fact and summarize it,” a focused web-capable session is usually preferable to a fully equipped workspace. The narrower the task, the more noticeable the improvement can be.

3. Focus

The best reason to scope down is cognitive: fewer irrelevant procedures means a clearer decision space. A writing task should not be distracted by deployment instructions. An image task should not need every infrastructure tool. A read-only research session may not need terminal access at all.

Focus also improves safety. Limiting tools makes accidental side effects less likely, while limiting skills makes it clearer which workflow rules govern the answer. This is especially valuable when handing a repeatable command to another person or embedding it in a script.

A simple rule of thumb

Use default mode when you are exploring, switching between domains, or unsure what the task will require. Scope down when the request is bounded and you can name its needed skills and tools.

Start with the smallest honest envelope, then widen it if the task reveals a missing requirement. For the example command, that means ABS and image generation, terminal and web, and Anthropic. Keep relevant memory and fact_store context available, but do not confuse “available” with “load every possible capability.”

The goal is not minimalism for its own sake. It is to give the agent enough context to do the job well—no less, and usually no more.