2.29 Billion Tokens and a New Kind of Teammate
What two months with Hermes Agent taught us about building companies with persistent AI
In 69 days, our Hermes Agent processed approximately 2.29 billion tokens.
It worked across 10,361 sessions and 45,965 model API calls.
Hermes has become a great addition to our team. It carries context across days. It works through long operational loops. It can research, write, inspect software, monitor systems, manage scheduled work, and turn what it learns into better instructions for the next run.
We did not set out to maximize token usage. We set out to understand what happens when an AI agent stops being a tool you occasionally prompt and becomes part of how a company operates.
The answer is that the unit of progress changes.
You stop thinking only in terms of conversations. You start thinking in terms of persistent systems.
The number behind the experiment
The 2.29 billion tokens break down like this:
Token category | Recorded usage |
|---|---|
Fresh or uncached input | 283,254,660 |
Output | 12,772,695 |
Cached input reads | 1,994,921,088 |
Total model traffic | 2,290,948,443 |
The system also reported 3,682,794 reasoning tokens separately. I did not add them again because provider accounting may include them within output usage.
The difference between fresh and cached input matters. Approximately 1.995 billion tokens were cached reads.
That is a sign of a system repeatedly working with durable context, not 2.29 billion tokens of newly written prompts.
If you exclude cached context, Hermes processed approximately 296 million fresh input and output tokens.
This is not a bill. It is not a valuation metric. It is not a substitute for users or revenue.
It is a measure of how much cognitive work can move through a persistent agent when that agent is connected to real tools, projects, schedules, and decisions.
The shift from chatbot to teammate
Most people first experience AI through a blank text box.
You ask a question. It answers. The interaction ends.
That is useful, but it leaves most of the value on the table.
Companies do not operate as isolated questions. They operate as loops:
understand what is happening
decide what matters
act
verify the result
retain what was learned
improve the next attempt
Hermes became valuable when we designed around those loops.
It has persistent memory for stable facts and preferences. It has skills for repeatable procedures. It reads project context from the environments where it works. It can run scheduled jobs. It can use tools. It can inspect past sessions. It can preserve operational state outside a single conversation.
That combination turns the agent into something closer to a teammate with continuity.
The most important feature is not that Hermes can generate text. Many models can do that.
The important feature is that the system can keep getting better at working with us.
What Hermes has helped us build
Over two months, Hermes has contributed across several parts of Samelogic.
A clearer company narrative
Strategy often fails because context gets fragmented. Product decisions live in one document. Customer language lives in another. Market evidence appears in conversations. The website says something older. A week later, everyone is operating from a different version of the company.
Hermes helped us consolidate that context into a durable source of truth and maintain it as our thinking evolved.
For Samelogic, this meant becoming more precise about the problem we solve.
We are building around an important browser-workflow problem: a failure often disappears when the receiving engineer opens a fresh page. The state, actions, page transitions, role, timing, or data that produced the failure are missing.
That led to a clearer message:
Samelogic captures the browser path a fresh-page repro skips, then sends the exact transition to Linear or Jira.
The product still creates replayable test artifacts. But the outcome now comes first. The mechanism comes second.
That change came from connecting product context, practitioner conversations, market research, and daily operating evidence. Hermes helped us turn all of that into one usable position.
A tighter connection between market learning and product work
One of the easiest traps in a startup is separating “go to market” from “product.”
The market team learns something. The product team ships from an older roadmap. Content continues using familiar language. The company gets busier without getting more aligned.
We use Hermes to keep these functions connected.
When practitioners tell us that useful handoffs require the last known-good state, page transitions, focused console or network context, and progressive disclosure, that should affect both how we speak and what we build.
Our current product implications are concrete:
Make first capture to saved replay to Linear or Jira the clearest activation path.
Surface the last known-good state and the transition into failure.
Present the evidence the receiver needs without overwhelming them.
Measure the path from source to install to first replay to first handoff.
This is the kind of work agents are unusually good at. They can hold the long context while still operating on today's evidence.
A persistent execution layer
Hermes also helped turn recurring company work into systems rather than reminders.
We now have structured workflows for:
market and buyer research
product and positioning analysis
outbound preparation and execution
inbox monitoring and follow-up management
publishing and community participation
software inspection, testing, and documentation
scheduled learning and reconciliation
The important word is not automation. It is persistence.
A persistent system does not forget the operating rules every morning. It knows where the source of truth lives. It remembers which account is authoritative. It understands the difference between a draft and a verified external action. It can check whether work has already happened. It can preserve the state required for the next step.
This creates leverage without requiring the team to re-explain the company every day.
A compounding learning system
Hermes has a built-in learning model based on memory and skills. We found that the practical value comes from treating every correction as an opportunity to improve the system.
If a process needs a new safeguard, add it to the procedure.
If a stable preference matters across sessions, save it to memory.
If a project has a non-obvious constraint, put it in the project context.
If a workflow succeeds after several iterations, turn it into a reusable skill.
This creates a different relationship with software. The system is not static. It learns how the team works and becomes more useful as the operating model becomes clearer.
The architecture of a useful agent
The most important setup decision is deciding where different kinds of knowledge belong.
We use four layers.
1. Project context
Project context explains the environment where Hermes is working:
repository structure
build and test commands;
coding conventions;
product terminology
source-of-truth files
security boundaries
completion and verification standards.
This keeps the agent grounded in the actual project rather than a generic approximation of it.
2. Memory
Memory should contain stable facts that prevent repeated steering:
communication preferences
authoritative tools and accounts
product boundaries
recurring business rules
durable operating preferences
Memory works best when it is compact. It should represent what remains true, not become a transcript of everything that happened.
3. Skills
Skills contain procedures.
A good skill explains:
when to use it
what must be checked first
the exact workflow
common failure modes
what requires approval
how to verify completion
This is how a successful one-time process becomes a repeatable company capability.
4. Runtime state
Queues, databases, ledgers, artifacts, and audit records belong in runtime state.
The agent can inspect them when needed without carrying every historical detail inside every prompt.
This architecture makes the system easier to reason about. Memory says what is true. Skills say how to work.
Project files define the environment. Runtime state records what is happening.
Verification is the foundation of trust
The most useful operating pattern we adopted is simple:
Inspect → decide → act → read back → reconcile
An agent should not call work complete because it attempted an action.
If it changes a file, run the relevant checks.
If it publishes something, inspect the public result.
If it sends a message, verify the sent record.
If it schedules a job, inspect the completed run.
If it updates a database, read the row back.
Verification changes the quality of autonomous work. It turns the agent from a generator of plausible progress into a system that can establish what actually happened.
This is especially important as the agent takes on longer workflows. The more steps involved, the more valuable explicit state and verification become.
How to set up Hermes well
If I were starting again, I would use the following sequence.
Step 1: Install Hermes
Nous Research provides a one-line installer for Linux, macOS, WSL2, and Termux:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash
Windows users can use the documented PowerShell installer. Hermes Desktop is available for Windows and macOS.
The official documentation recommends this setup path:
hermes setup --portal
This connects a model and Tool Gateway access through Nous Portal.
Step 2: Connect one messaging platform
Hermes can work through Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Microsoft Teams, Google Chat, email, SMS, and other platforms.
Start with one.
I use Telegram because it makes the agent available wherever I am while the working environment stays on the machine running Hermes.
The benefit is subtle but important. The agent becomes part of the operating rhythm rather than something confined to an IDE window.
Step 3: Give it one serious project
Do not begin with ten disconnected experiments.
Choose one project with real context and recurring work. Give Hermes:
the project location
the source of truth
the commands it should use
the language the team uses
the boundaries it must respect
the evidence required before calling work complete
The quality of the context will matter more than the cleverness of the first prompt.
Step 4: Start with read-only workflows
Good first workflows include:
repository analysis
documentation audits
market research
analytics review
inbox summaries
issue and pull-request inspection
daily operating briefs
Read-only work gives the agent a chance to learn the environment and gives the team a chance to evaluate its judgment.
Step 5: Add one repeatable skill
Choose a workflow the team performs often.
Document the trigger, steps, boundaries, outputs, and verification. Then improve the skill when reality exposes a missing step.
A skill becomes a small piece of operational infrastructure.
Step 6: Add one scheduled loop
A good first scheduled job owns one clear transition:
morning inbox triage
nightly product-learning review
weekly project health check
daily analytics summary tied to a decision
queue reconciliation
Avoid instructions like “grow the company every hour.” Broad jobs create broad activity. Narrow jobs create accountable systems.
Step 7: Add one controlled action path
Once the read-only work is reliable, allow one type of external action.
Make the path explicit. Define the authorized account, destination, constraints, duplicate checks, and read-back verification.
The agent should earn broader responsibility through demonstrated reliability.
Step 8: Build a learning loop
At the end of each day or week, ask:
What did we believe?
What did we try?
What happened downstream?
What did we learn?
What changes in the product or message?
What is the next test?
This is where an agent becomes more than an automation layer. It becomes part of the company's ability to learn.
How to think about token usage
A large agent system will use more tokens than a chat interface because it is doing more than chatting.
It may carry project context, inspect state, call tools, recover prior work, run scheduled jobs, and verify external results.
The right question is not whether the number is large. The right questions are:
Which workflows consume the most?
Which ones change decisions?
Which ones produce durable outputs?
Which context is repeatedly useful?
Which jobs can be narrower?
Which no-change runs should remain silent?
Caching matters. Tool restrictions matter. Compact handoffs matter. Keeping historical detail in searchable state rather than every prompt matters.
We can make the next billion tokens more efficient by:
Restricting each job to the tools and skills it needs.
Passing structured summaries between workflows.
Keeping large histories in ledgers and databases.
Retrieving only the relevant prior-session window.
Combining overlapping scheduled jobs.
Silencing runs that discover no meaningful change.
Measuring each workflow against a decision or external outcome.
But efficiency should follow usefulness.
The first job is to build the right system. The second is to make it cheaper and faster.
What this suggests about the future of teams
The current generation of agents is often discussed as if the main question is whether they replace individual tasks.
That may be too narrow.
The more interesting question is what happens when every small team can have persistent intelligence operating across its projects, tools, memory, and schedules.
A capable agent can help a team maintain context that would otherwise be lost. It can connect market evidence to product decisions. It can keep recurring work moving. It can make procedures executable. It can preserve lessons. It can reduce the distance between a decision and verified action.
This does not remove the need for judgment. It makes judgment more scalable.
The team still decides what matters, what is true, what risks are acceptable, and what future it wants to create.
The agent helps carry that intent through thousands of small steps.
That is what has been exciting about Hermes for us.
It has not felt like adding another software subscription. It has felt like adding a new kind of teammate, one that becomes more useful as the team becomes more explicit about how it operates.
Final takeaway
The headline is 2.29 billion tokens in 69 days.
The outcome is a company operating system that can remember, execute, verify, learn, and improve.
Hermes has helped us clarify our thinking, connect market learning to product direction, build persistent workflows, and increase the amount of high-quality work the team can carry at once.
We are still early. That is the exciting part.
The systems we are building today will look primitive compared with what persistent agents become over the next few years. But the pattern is already clear.
Start with one important project. Give the agent real context. Define the boundaries. Require verification. Preserve what it learns. Expand its responsibility as trust compounds.
The teams that learn how to work this way will be able to move with a level of continuity and leverage that used to require much larger organizations.
Hermes has been a great addition to our team. The 2.29 billion tokens are only the beginning.
Resources
Related workflows
Move from editorial context into the selector, Playwright, and bug-reproduction pages that turn exact UI evidence into action.
