How to build a Hermes Agent-style workflow

(This is the second in a three-part series about Hermes Agent and similar agent harnesses. Part 1 introduced the problem of token caps and the case for owned context. Part 3 will cover getting Hermes Desktop up and running — the setup, skills, and workflows.)

Chaining AI tasks together — pulling a Salesforce record, checking a data warehouse, drafting a report — is one of the most powerful capabilities to emerge from the current wave of AI tools. But every one of those calls costs tokens, and a single afternoon of serious tool-calling can burn through a $20 subscription. The fix is an architectural shift: moving your data out of the provider’s ecosystem and into storage you control.

The open-source Hermes Agent is one implementation of this approach. It uses three components to keep your context on your infrastructure and send the model only the information it needs.

A system with three parts

1: A local context store. Instead of having every piece of information your AI touches pass through an external provider’s walled garden, you keep the raw data in storage you control — a shared team database, a cloud data warehouse like Snowflake or BigQuery, even just a folder in shared cloud storage. 

When the agent needs data from a live business system — pulling account records from Salesforce via an MCP connection, querying audience segments from a CDP, or checking campaign performance in your data warehouse — it makes the call, and the response lands in the context store before anything reaches the model. The store becomes the single holding area for everything the AI touches, whether the data arrived pre-loaded or was fetched fresh moments ago. The LLM reads from the store and never reaches directly into your CRM or CDP.

2: Skill library: It contains the voice guides, style rules, past articles, and brand documents that your AI draws on for tone and context. Instead of pasting the same brand guidelines into every prompt, they are stored in a local directory that the agent can search. When a new task comes in, a simple keyword or vector query — not an LLM call — finds the most relevant excerpt and passes only that snippet to the model. That costs pennies regardless of how large your reference library grows. The model never sees the full document, and you never pay to send your entire knowledge base through the token meter.

3: A minimal-prompt extractor. This is a simple piece of logic — keyword scoring, vector similarity, or a straightforward database query — that looks at the incoming task, checks the context store for the most relevant information, and passes only that slice to the LLM. When the store does not have the data the task requires, the extractor can trigger an MCP call to your CRM, an API request to your CDP, or a query against your data warehouse. Then the response lands in the store to be processed like any other piece of data. The extractor does not call an LLM for any of these steps. It runs for pennies, regardless of volume.

Setting up this filtering logic might involve an LLM once, the same way you might use an AI assistant to write a formula or a script. But once in place, it runs automatically on every batch of new data without calling an expensive model.

How data moves through the system follows a consistent sequence. Fresh data arrives from a CRM, CDP, or data warehouse and lands in the context store. When a task comes in, the extractor checks the store for the most relevant information, pulls the relevant excerpt, and combines it with reference material from the skill library. Only that assembled package reaches the LLM. The model processes it and returns a result, which gets stored back in the local context store. Every step before the model call runs without incurring token costs.

A mindset change

How this comes together in practice starts to look less like a technical implementation and more like a shift in how you think about AI workflows.

Most marketers approach AI the same way they approach a search engine: Type in a request, get a result, and start over next time. That is the prompt-centric model. The prompt is the starting point for everything. Your question, the model’s answer, maybe a follow-up or two — and then the context evaporates into the provider’s interface. Next time, when you need something similar, you start from scratch. The model learns nothing from what came before.

The Hermes-style model inverts that habit. The prompt becomes the final step, not the first one. The real work happens before the prompt is written: Data arrives in the context store, the extractor finds the relevant slice, and the skill library supplies the voice and rules. By the time the model sees anything, the question has already been filtered, assembled, and prepared. The model’s job narrows to a single reasoning task: Generating the outcome using data you have already curated.

That change has consequences beyond token savings. In a prompt-centric workflow, institutional knowledge lives in scattered conversation threads. Each new task requires someone to remember what was done previously and manually reconstruct the context. In a context-centric workflow, the store accumulates everything. Every task contributes to the next one. A brand brief written in January serves as reference material for a campaign brief in June, so no one has to dig through old conversations.

The same logic applies to how teams work together. When a new marketing coordinator joins mid-campaign, they do not need to scroll through weeks of chat history to understand the brand voice, audience definitions, and competitive positioning. Those live in the skill library and the context store. The new team member can start contributing meaningful work from day one because the team’s accumulated knowledge is accessible to the agent — and, through it, to them.

This is where the architecture reveals its real value. The token savings are immediate. But the compounding effect of a system that learns from every interaction is what changes how a team operates over time.

Your customers search everywhere. Make sure your brand shows up.

The SEO toolkit you know, plus the AI visibility data you need.

Start Free Trial

Get started with

Hermes Agent has a memory layer that stores preferences, corrections, and recurring patterns as you work. When you correct the agent’s tone on a draft, that correction feeds into future drafts automatically. When a particular workflow proves effective, the agent can save it as a skill — so the next time you face the same type of task, the reference material and process are already in place. The system gets better at working with you the more you use it, without requiring you to document everything manually.

Recommended Articles

The latest AI-powered martech news and releases

Jul 2, 2026

FREE! The email subject line rules that don’t hold up!

Jul 2, 2026

Stop adopting AI and start solving problems

Jul 2, 2026

Before you build

One thing the architecture does not solve on its own is model choice. Submitting the same query to two different models can produce dramatically different results, and the quality of your output still depends largely on which model is doing the reasoning.

The advantage of a provider-agnostic layer like Hermes Agent is that you can swap models freely — test the same pipeline against a free OpenRouter model, a paid Anthropic one, or a self-hosted LLaMA — without rearchitecting anything. The savings from the pattern are consistent across models. The quality is not, and that is worth testing.

There is also an organizational hurdle: a $20/month subscription only needs a credit card. API access often requires procurement, a security review, and someone to own the variable bill. The subscription model persists partly because it is frictionless to buy, even when it is more expensive over time. Teams adopting this approach should budget for that organizational lift alongside the technical setup.

Some teams have tried to work around subscription limits by routing an Anthropic subscription through an agent harness. Anthropic has cracked down on that practice, enforcing API-level terms regardless of how access is tunneled. The provider’s pricing model is not an accident you can route around — it is the intended structure of the service. The only way to escape the ceiling is to change what the model sees.

Putting the pattern to work

Generating ad copy

A typical ad copy generator pipeline may call for five headline variations based on product specs stored in an internal system. In a traditional setup, you would prompt the model with the full product description, brand guidelines, campaign brief, and audience definition. All of that context travels through the LLM every single time.

With the Hermes-style approach, the pipeline works differently.

The agent pulls the product specs from the internal API and stores the raw JSON locally. A lightweight query extracts the high-priority fields — price, key features, target audience — roughly 300 tokens worth. The brand voice guide sits in the skill library, not in the prompt. The LLM receives only the extracted spec and generates the headline variations. The response gets stored locally for the next step. The final copy is pushed to the CMS. (All token estimates are based on standard tokenization metrics used across the industry.)

The token bill for this would be roughly 450 tokens, compared to well over 1,000 for the full-context approach. The output quality remains the same, but the cost is more than halved.  

Real-time social listening

In a real-time social listening workflow, the agent polls the X/Twitter API for mentions of a set of brand keywords every five minutes. Each batch of raw tweets is stored locally. Once an hour, the relevance filter runs uses simple keyword scoring on the tweets — no LLM involved — and identifies the 20 most relevant posts. Those 20, roughly 400 tokens in total, are passed to the model for sentiment analysis and used to create a five-bullet brief. The body of raw data never touches the model.

The per-hour token cost would drop substantially — from an estimated 3,000 to roughly 600 — and the output is unchanged

Neither of these pipelines requires significant infrastructure work. The first can be set up in a few minutes. Install the package, create a marketing profile, set the free OpenRouter model as your default, enable the toolsets you need, and point the local store to a directory of your choice. A single command — something like summarizing the top tweet from a feed — will run the whole loop and show you exactly how many tokens were consumed in the process.

The second pipeline requires a bit more orchestration: a cron job or scheduled task for the polling loop, and a lightweight script for the relevance filter. But the core pattern — store first, extract, then call the model — is the same. And because the agent is provider-agnostic, you can swap the underlying model from OpenRouter to a self-hosted instance without touching the pipeline logic.

It’s the architecture, stupid

This is why the architecture matters more than any specific tool. Hermes Agent makes the pattern straightforward to adopt, but the pattern itself is what drives the savings. An organization comfortable with Python scripts and a shared database could replicate the same approach without adopting any new platform. The habit of storing first and extracting before calling the model is what’s key.

And that habit applies beyond the two examples here. Dynamic content personalization, customer profile enrichment, competitive intelligence gathering, campaign performance analysis — any workflow where you are currently feeding raw data directly into an LLM prompt is a candidate for this approach. The savings start the moment you stop treating the model as the first stop for your data and start treating it as the last.

This is the second in a three-part series about Hermes Agent and similar agent harnesses. Part 1 introduced the problem of token caps and the case for owned context.