Agentic Context Engineering for Hermes and Private AI Assistants

Reliable agents do not need one giant prompt. They need clean working context: stable rules, current state, durable memory, useful skills, narrow tools, and explicit approval gates. For Hermes, context engineering is the operating system around the assistant.

Give Hermes different kinds of context in different places. Put durable operating rules in a runbook or project instruction file. Put current state in source systems or project files. Put stable preferences in memory. Put repeatable procedures in skills. Put the immediate request in chat. Connect tools only after the assistant knows when to stop and ask.

Good context makes the assistant easier to correct. Bad context makes mistakes harder to trace.

The five context layers

Use this split for most private AI assistant workflows.

1. Operating rules: role, purpose, approvals, forbidden actions, tone, source priorities.
2. Current state: open deals, active projects, calendar events, current tickets, today’s priorities.
3. Durable memory: stable preferences, durable facts, repeated corrections, owner style.
4. Skills: reusable procedures for repeated tasks.
5. Task request: the immediate ask, deadline, constraints, and output format.

Do not collapse all five layers into one prompt. The owner should be able to update each layer without breaking the others.

Operating rules: write decisions, not vibes

A useful rule changes behavior at a decision point.

Weak rule:

> Be careful with customers.

Better rule:

> Draft customer replies from approved source messages, cite the source, and ask for approval before sending, quoting price, promising a timeline, or changing CRM status.

The better rule defines the action, evidence, and stop condition.

For a small business, operating rules should cover:

• what the assistant is for;
• which sources are trusted;
• what it may read;
• what it may draft;
• what it must never do;
• what requires approval;
• where receipts are logged;
• when to escalate.

Readable Markdown is useful because a founder or operator can review it without opening a hidden prompt builder.

Current state: keep it refreshable

Current state changes too often to live in memory or permanent instructions.

Better homes for current state:

• CRM records;
• project tracker issues;
• calendar events;
• support tickets;
• a current status file;
• a weekly planning doc;
• a folder of source notes.

If today’s priorities change every morning, let Hermes read today’s priorities from the right place. Do not bury them in durable memory.

Memory: durable, small, and reviewed

Memory should help Hermes avoid repeated corrections. It should not become a warehouse for every conversation.

Save to memory when a fact is:

• stable;
• useful across sessions;
• safe to retain;
• hard to infer from the source systems;
• approved by the owner or obvious from repeated corrections.

Good memory:

• “The owner prefers short customer replies with no exclamation marks.”
• “Use the CRM as the source of truth for deal stage.”
• “For support drafts, ask before offering refunds.”

Bad memory:

• one-off customer details;
• passwords or API keys;
• temporary task lists;
• stale project status;
• unverified claims from a single message.

Review memory on a schedule. Delete what is stale or too sensitive to justify keeping.

Skills: reusable procedures, not permanent facts

Skills are for repeated “how to do this” knowledge.

Examples:

• how to prepare a meeting brief;
• how to draft a lead follow-up;
• how to summarize a Slack thread;
• how to produce a weekly owner report;
• how to turn a support ticket into a reply draft.

A skill should include inputs, allowed tools, blocked actions, approval gates, output format, and escalation rules. If a skill says “handle customer support,” it is too broad. If it says “draft support replies from approved tickets and ask before refunding,” it is useful.

Task requests: keep the immediate ask explicit

The chat or ticket should hold the immediate request.

Include:

• what you want produced;
• deadline or time horizon;
• source links or file names when known;
• output format;
• constraints;
• anything unusual about this run.

Example:

> Use the lead follow-up skill on today’s new form submissions. Return a table with source, classification, draft, risk, and approval question. Do not send anything.

This keeps temporary instructions out of memory and permanent files.

Tools: context before capability

Tool access magnifies context quality. If the rules are messy, tools let the assistant make messy changes faster.

Before connecting a tool, answer:

1. What can Hermes read?
2. What can it draft?
3. What can it change?
4. What must require approval?
5. What receipt remains?
6. How can access be revoked?

For MCP servers, plugins, browser access, filesystem access, and app integrations, start with the narrowest useful surface. Add more tools only when the runbook needs them.

Approval gates are context too

Approvals are not separate from context engineering. They tell the assistant where preparation ends and commitment begins.

Require approval for:

• outbound customer messages;
• pricing, refunds, discounts, legal, financial, medical, hiring, or timeline commitments;
• public publishing;
• deleting or archiving source material;
• billing or production changes;
• CRM status changes that affect reporting;
• any action the owner would need to explain after a mistake.

An approval request should include source, proposed action, exact output, risk, and result after approval.

Receipts prevent context drift

Every recurring workflow should leave a receipt.

A receipt can be a Slack thread, Telegram message, email summary, CRM note, project comment, or log entry. It should answer:

• what triggered the run;
• which sources were inspected;
• what Hermes concluded;
• what it drafted or changed;
• who approved it;
• what remains open.

Receipts make future context better. They also make mistakes easier to repair.

Worked example: morning briefing context

A founder wants Hermes to prepare a weekday morning briefing.

Use this context design:

• Runbook: purpose, trusted sources, blocked actions, approval rules, receipt format.
• Current state: calendar, CRM tasks, open invoices, project tracker, current status file.
• Memory: preferred briefing length, tone, and source priority.
• Skill: procedure for selecting urgent items and formatting the briefing.
• Task request or cron: “Run every weekday at 8:30am and return max five bullets.”
• Tools: read-only calendar, CRM, inbox, and project tracker at first.
• Approvals: required before sending emails, changing records, or moving meetings.
• Receipt: daily owner summary with skipped items and uncertainty.

This is more reliable than “check everything and tell me what matters.”

Common mistakes

Mistake 1: using memory as a junk drawer

If everything goes into memory, nothing is trustworthy. Save only durable, useful, safe context.

Mistake 2: hiding current state in permanent instructions

Permanent files should not contain this week’s moving target. Put live state where Hermes can refresh it.

Mistake 3: writing vague rules

“Be accurate” does not tell Hermes what to do. “Cite the source and ask when the source is missing” does.

Mistake 4: adding tools before stop conditions

If the assistant does not know when to ask, it is not ready for write access.

Mistake 5: skipping receipts

Without a receipt, the next run has weaker context and the owner has less trust.

First implementation plan

1. Pick one workflow, such as lead follow-up or morning briefing.
2. Write a short runbook with allowed and blocked actions.
3. Identify the real source of truth for current state.
4. Save only stable preferences to memory.
5. Create one skill if the procedure repeats.
6. Connect the smallest useful tool set.
7. Require approval for external actions.
8. Review the first five receipts and update the context layer that failed.

Fix the source of confusion, not just the prompt wording.

Recap

Agentic context engineering is mostly separation. Runbooks hold rules. Project files and source systems hold current state. Memory holds durable preferences. Skills hold repeatable procedure. Chat holds the immediate request. Tools come after boundaries. Approvals and receipts make the system trustworthy.

Next step

For setup, read Hermes Agent Runtime for Business Workflows. For reusable procedures, read How to Use Hermes Skills for Repeatable Business Workflows. For security boundaries, read Hermes AI Agent Security Checklist for Small Teams. To see it in action, try the Engineering Product Ops Agent demo.