Running a Company in a Chat Window: context engineering an agent harness on one home server
Audience: operators who would build their own agent harness. The essay Nobody Buys Software Anymore. They Describe It. argues for owners that AI collapsed the cost of building software. This paper shows, for operators, the machine that runs on that premise: how it is wired, how its context stays coherent, how to copy it, and what breaks. Essays argue. This shows.
All operating numbers and file names in this paper were taken from the running system in September 2026. No secrets appear here. Where a real key, token, or address would go, a placeholder stands in its place, marked as such.
1. The claim
A company can run from a chat window on one home server. The operating numbers behind that sentence are small enough to write on a card:
- 6 agent profiles form a council: one Director and five specialists
- 61 scheduled jobs on file in the Director profile, 39 enabled
- 1 chat workspace (Discord) that is the operating record
- 1 machine: an ODROID single-board computer (ARM) in a home office
The same board that runs the company also serves the public site, trivanceai.com, through a Cloudflare tunnel to a local PM2 server, and it runs the preview sandbox where pages and posts are checked before they go live. The About page photograph of the homelab shows the actual board, not a stock image.
Nothing about this setup is exotic. There is no GPU farm, no orchestration framework, no cluster. The heavy machinery is a chat application, an agent runtime that can be driven from a terminal, and a cron scheduler. The hardware fits in a desk drawer and draws less power than a light bulb. What makes the arrangement work is not the hardware. It is the discipline of context: keeping six agent personalities coherent across dozens of recurring jobs while each one only ever carries a small, deliberate slice of the company in its working memory at any moment.
That discipline has a name in this paper: context engineering. It has three mechanisms that do nearly all the work, plus two rules that contain the failures. The mechanisms are profile-level memory, skills that load on demand, and one-shot dispatch. The rules are: decide where data lives, and decide who reviews output. Everything else in this paper is detail around those five ideas.
The honest caveats come early, because operators should trust a paper that states its own limits. This is a description of one running system, not a vendor benchmark. It is not a claim that agents replace people, and it is not a claim that the system cannot break. It breaks in predictable ways, cataloged in section 5, and each failure has a rule that contains it. What the paper does claim is that the pattern is copyable: the configuration in section 4 is written so that an operator with a weekend and a spare machine can reproduce the shape of it, with placeholders where secrets belong.
2. The architecture
Four layers, bottom to top: the machine, the runtime profiles, the workspace, and the schedule.
2.1 The machine
One ODROID board runs the whole arrangement on Ubuntu. Profiles run as Hermes Agent sessions under a user account, and the public site runs as a local PM2 server. A Cloudflare tunnel exposes that local server to the public internet as trivanceai.com, so there is no inbound port forwarding and no static IP dependency. The preview sandbox runs on the same board, isolated from the public site, so draft pages and copy can be inspected before they are wired into production.
This matters for a reason beyond cost. When every piece of the operation lives on one board, the operator can see all of it, back up all of it, and explain all of it. There is no distributed estate to map. The trade is real and named in section 5: one board is also one failure domain, and the maintenance burden has no vendor behind it.
2.2 The council: six profiles, one Director
Hermes Agent organizes agents as profiles. A profile is a directory that holds everything one agent needs: its identity file, its memory stores, its skills, its scheduled jobs, its session history, its logs, its configuration, and its secrets file. Six profiles make up the council:
- director-1, the Director: routes work, runs the schedule, and synthesizes results
- researcher-1: research and evidence gathering
- dev-3: software development
- pixel: design and visual work
- ops-5: operations
- press-1: content and writing
One Director and five specialists. The Director is the only profile wired to the chat gateway as the primary operator of the workspace. The specialists are invoked one at a time with self-contained tasks.
The division is not cosmetic. Each profile carries its own memory and its own skills, which means each specialist only ever has the context its role needs. The Director does not carry the content writer's style notes, and the content writer does not carry the developer's deployment runbooks. Section 3 explains why that separation is the core trick of the whole system.
2.3 The workspace
The workspace is a Discord server. It is where tasks arrive, where results are posted, where the daily briefings land, and where the humans who own the company read what the agents produced. The chat log is the operating record: what was asked, what came back, and what the humans decided about it. Channels separate kinds of traffic, and pinned messages hold the standing conventions that do not belong in any single agent's memory.
A gateway process connects the agent runtime to Discord. The gateway auto-starts, and it runs unattended. One quirk worth knowing before it surprises you: the presence indicator can show the gateway as offline while it is working normally. Do not trust the green dot. Trust the outputs.
2.4 The rhythm
The company runs on a schedule more than on demand. The cron fleet lives inside the Director profile: 61 jobs on file, 39 enabled in the September 2026 snapshot. Each job has an id, a name, a prompt, a schedule, and a model assignment. The jobs set the daily beat:
- a morning brief every day at 8AM Central
- a cost digest every morning, so spend never goes unexamined for long
- payroll news refreshes and an inbox report for the payroll system
- a memory digest that summarizes activity to the memories channel every two hours
- market watchers and resolution trackers that run continuously
- cross-venue race arms for scheduled economic releases such as NFP, CPI, and FOMC decisions, so the company reads the news as it lands rather than after the market has moved
Humans steer the rhythm from the chat window: reading briefings, approving direction, and dispatching one-off tasks that do not belong on a schedule. That mix is the whole shape of the operation: scheduled agents for the recurring work, on-demand agents for the specific asks, and a human at the top of the loop for the calls that carry judgment.
3. Context engineering
Every agent harness has the same problem under different names: a model can only think about what is in front of it, and what is in front of it costs money and attention. Put the whole company in every context and each task gets slow, expensive, and muddled by irrelevant history. Put nothing in the context and each task starts from zero and gets the answer wrong. Context engineering is the practice of deciding, deliberately, what each agent sees when it works. It is the difference between a harness that produces coherent work across many domains and a pile of scripts that produce plausible nonsense.
This system uses four mechanisms. None of them is exotic. Together they are what make one small model, on one small board, useful across the many domains a company touches.
3.1 Profile-level memory: the durable slice
Each profile keeps two memory files. One holds facts about the user the agent serves: who they are, how they prefer to work, what standards they hold. The other holds the agent's own notes: environment facts, tool quirks, standing conventions, lessons from past work. The files are small, measured in hundreds of characters, not megabytes. They are injected into every session for that profile.
The discipline is in what does not go into memory. Memory is not a filing cabinet. It is the small set of facts that apply to every session regardless of task. Procedures, command recipes, and pitfalls belong in skills (section 3.2), which load only when relevant. Task state and progress belong in session history and the workspace, not in memory. When memory fills, entries get consolidated or dropped, because a memory store that grows without bound stops being context and starts being noise.
The result: the content profile carries the company's voice rules and evidence standards, the developer profile carries deployment facts, and neither carries the other's. Six agents, six small slices, none of them carrying the whole company.
3.2 Skills on demand: procedural memory that stays out of context until needed
The second mechanism is the one that keeps one model competent across many domains. Skills are structured documents, loaded into context only when the task matches. A profile may hold dozens of skills, but a session starts with a list of skill names and one-line descriptions, not with the full text of every skill. When the task at hand touches a skill, the agent loads it and follows it. When it does not, the skill never enters the context.
An example from this paper's own production: the content profile holds writing skills that encode the house voice rules (no em dashes, no ellipses, no exclamation points, ASCII only), a humanizing pass that strips AI tells, and workflow skills for turning transcripts into posts. Those skills load when a writing task arrives and not when the same profile is asked to check a file listing. The research profile holds citation and monitoring skills that load when evidence is being gathered. The same underlying model, pointed at the same board, does both jobs well because each job pulls in only its own procedure manual.
This is the load-bearing trick of the whole arrangement. Skills-on-demand is what lets a single small model behave like a team with specialties, and it is what keeps context budgets small enough that a home server can run the operation on consumer API pricing. Without it, either every task would carry every procedure (and blow the context window) or no task would carry any (and every task would reinvent the procedure, badly).
3.3 One-shot dispatch: the company does not ride along
The third mechanism is how work moves between profiles. The Director dispatches a task to a specialist with a one-shot terminal command:
hermes -p press-1 chat -q "<task>"
The -p flag names the profile. The -q flag passes the task as a single self-contained question. The specialist runs, produces a result, and exits. It does not carry the morning brief, the payroll digest, or the last dozen tasks in its context. It carries its profile memory, the skills relevant to the task, and the task itself.
The task text is written to be self-contained. It says what to produce, which verified facts to use, which constraints apply, and where the output goes. This is a skill in itself: dispatch prompts are written so that a profile with zero recollection of the company's last week can do the work correctly, because most of the time that is exactly the situation.
The Director may also delegate reasoning-heavy subtasks to subagents with isolated contexts, each with its own terminal and its own toolset, where only the final summary returns to the caller. This is the same principle applied one level down: when a piece of work would flood the caller's context with intermediate material, push it into a fresh context and bring back only the conclusion. Research sweeps, verification passes, and long analysis runs are the natural candidates.
One-shot dispatch has a side effect that is worth naming because it is a feature. Because every task arrives complete and leaves complete, the operation has no long-running conversational state to corrupt. A session that goes sideways can be discarded without damaging the company. The cost is that a specialist cannot remember the conversation it had yesterday. That is by design. If a task needs yesterday's output, the task text points at where that output lives, and the specialist reads it from the record (section 3.4).
3.4 The workspace as operating record
Every mechanism above assumes that durable state lives somewhere other than an agent's head. It lives in the workspace. The Discord chat log is the operating record of the company: dispatches, outputs, decisions, corrections, all in one searchable place that predates any single session and outlives them all. Channels separate the streams, and pinned messages hold the standing conventions that every participant, agent or human, can consult.
Two consequences follow. First, a specialist that needs history does not remember it; it reads it. The content profile does not recall the house style guide from memory alone, it has it in a skill, and when a task references a previous essay, the task says where the essay file lives on the board and the agent reads it. Second, the record is the audit trail. When a question comes up about what was produced and why, the answer is in the chat log and in the profile session files, not in somebody's recollection of a conversation.
The rule that governs all of this is stated plainly in section 6: decide where data lives. The workspace holds the operational record. The company's systems of record, the payroll platform, the financial accounts, the repositories, hold their own data and stay authoritative over it. Agents read from both and write results into the workspace and the filesystem, and they do not quietly accumulate a private second copy of the truth that can drift out of agreement with the source.
3.5 Verification discipline
The last habit is not a mechanism so much as a standing rule about what counts as done. In this system, a tool call that returns exit code zero is not a completed task. It is the start of the verification step. Output gets checked against the request, JSON gets parsed and validated, links get fetched, images get rendered and looked at, file writes get read back. A self-report of "done" from any agent, including this one, is treated as a claim to verify, not a fact to record.
The standard is deliberately concrete. When a dashboard is rebuilt, the agent checks that every row is present, not a sample. When a document is written, the word count is measured and the forbidden characters are grepped out of the file. When a deployment is claimed, the running process is checked and the health endpoint is hit. The evidence standard is real tool output: exit codes, file hashes, database events, rendered artifacts.
This discipline exists because the failure mode it prevents is the most expensive one in the whole system. A model that writes plausible text will also write plausible claims of success. The verification gap, named in the essay You Built It. Now You Own It., is that generation outruns review. The containment is not more generation. It is the rule from section 6: who reviews the output. Every consequential artifact has a reviewer, sometimes a second agent, sometimes a human, and the review checks the artifact against reality, not against the artifact's description of itself.
4. How to copy it
This section is written to be followed. It assumes you have a machine running a supported Linux, a Hermes Agent install, and an API key for the model provider of your choice. Where a real value would appear, this paper shows a placeholder in angle brackets, like YOUR_API_KEY, and says so. Nothing in this section requires a second machine, a GPU, or a cloud account, which is the point. The whole pattern fits on one board.
4.1 Create the profiles
Hermes Agent keeps every agent in its own profile directory. A profile is created and invoked by name with the -p flag, and each profile has its own configuration, secrets file, memory, skills, cron jobs, sessions, and logs. The council pattern is six profiles: one Director and five specialists. You do not need six at first. Two will teach you the pattern: a director and one specialist. Add roles as the work actually demands them, and rename them to fit your operation. The names in this paper are this company's names.
To create a profile, use the profile management command of your Hermes install, or start a session against a new profile name and let the runtime create it. After creation, each profile directory contains at minimum the files described in section 4.2. Verify creation by listing the profile directory before you write anything into it.
4.2 The per-profile directory
Every profile owns a directory that contains everything the profile is. On this system the profiles live under a profiles directory in the user's home, one subdirectory per profile name. The map in section 7.1 shows the real tree of one profile; the important members are:
- SOUL.md: the identity file. Who this profile is, what it is responsible for, and how it behaves. Written in plain language, read at the start of sessions.
- config.yaml: the profile's configuration. Selects the model and provider, points at the secrets file, and controls which skills and tools the profile may use.
- .env: the secrets file. Holds API keys and tokens. It is the one file that never appears in backups that leave the machine, never gets pasted into documents, and never shows up in the chat log.
- memories/: the durable memory store. Two files, one for facts about the user and one for the profile's own notes (section 3.1).
- skills/: the procedural memory. One subdirectory per skill, each holding a SKILL.md plus any reference files the skill needs (section 3.2).
- cron/: the profile's scheduled jobs and their execution log.
- sessions/: transcripts of past sessions, searchable when the record needs to be consulted.
- logs/: runtime logs, including an error log that the maintenance ritual reads first.
- state.db: the profile's local database of sessions and state. Files that end in -wal and -shm are SQLite companions and are normal.
Keep the directory boring. The profile directory is a stateful thing on purpose: it holds memory and history. Back it up whole (section 4.7) and never hand-edit its internals while a session is running.
4.3 Configuration essentials
Each profile's config.yaml does the same job: it declares which model the profile runs on, which provider serves it, and which capabilities the profile may use. The exact key names differ between Hermes versions, so this paper describes the role and shows the shape rather than a schema to paste blindly. A minimal configuration, with every secret replaced, looks like this:
# Illustrative. Key names vary by Hermes version; check your install.
profile: press-1
model:
name: <YOUR_MODEL_NAME>
provider: <YOUR_PROVIDER>
skills:
enabled: true
secrets_file: .env
The line that matters most is the model line, because the model is the smallest unit of cost and capability. In this operation the profiles run on a small, fast model for ordinary work, and the Director can override the model for a single hard task when the situation calls for it. Budget for that pattern: cheap by default, expensive on purpose, and never expensive by accident.
Secrets do not belong in config.yaml. They belong in .env, the profile's secrets file, which config.yaml references. The rule is mechanical: any value that would hurt if it leaked goes in .env, and .env stays off the machine only in encrypted backups. Every key in this paper is a placeholder. YOUR_API_KEY is not a key. Neither is anything in section 4.6 that looks like one.
4.4 The dispatch command
Work moves between profiles with one command shape:
hermes -p <profile> chat -q "<task>"
The task text is the whole interface. Write it self-contained: what to produce, which facts are allowed, which constraints apply, where the output goes. A well-formed dispatch needs no follow-up. This paper itself is the product of such a dispatch: one self-contained task to the content profile, with verified facts attached, a required structure, and a required deliverable path. The profile had no memory of the company's week. It did not need any.
For work too big for one context, the Director delegates subtasks to subagents with isolated contexts, each with its own terminal and toolset, and only the final summaries return. Use that when intermediate material would flood the caller: multi-page research sweeps, parallel verification passes, anything with a lot of reading and a short conclusion.
4.5 Cron anatomy
Recurring work lives in the cron fleet of the Director profile. Each job has an id, a name, a prompt, a schedule, and a model assignment, and a job may also name a set of skills, run a named script instead of prompting an agent, or run with no agent at all. The schedule comes in two kinds: a cron expression for calendar time, or an interval in minutes for recurring loops.
The morning brief is the cleanest real example, sanitized here. Every field that would identify the operation or touch a secret is replaced:
{
"id": "job-morning-brief",
"name": "Morning Brief - Daily 8AM",
"prompt": "Write the morning brief for <CHANNEL>. Read the overnight digest at <FILE_PATH>, fold in the market watch results posted since midnight, and summarize what changed and what needs a human decision. Deliver the brief to <CHANNEL>.",
"schedule": {
"kind": "cron",
"expr": "0 8 * * *"
},
"skills": ["<SKILL_NAMES>"],
"model": "<YOUR_MODEL_NAME>",
"deliver": "<DISCORD_CHANNEL_ID>"
}
The expression "0 8 * * *" means the job fires at 8:00 every day. The prompt is written the same way as a dispatch: self-contained, pointing at the record instead of assuming the agent remembers it. The delivery target is a Discord channel, which is how the output reaches the workspace where humans read it. The skills field loads the procedures the job needs without loading everything. The model field is where the cheap-by-default rule shows up: most jobs run the small model, and only the jobs that need more reasoning get the expensive one.
Two other job shapes are worth knowing. A job with a script field runs a named script rather than prompting an agent, which is how pure mechanical work stays cheap. A job marked no_agent runs the pipeline with no model call at all. The art of the fleet is matching the shape to the work: prompt an agent when judgment is needed, run a script when it is not, and never pay a model token for a step that a shell command can do.
4.6 Gateway wiring
The chat workspace stays connected through a gateway process that bridges the agent runtime and Discord. The concept is simple: the gateway runs as a service on the board, authenticates to Discord with a bot token, and relays messages between the workspace and the runtime. The token is a secret. It lives in the secrets file of the gateway's profile, never in a document and never in this paper. YOUR_DISCORD_BOT_TOKEN is where your real token goes when you wire your own.
The gateway auto-starts and runs unattended. Plan for two facts from the start. First, the gateway's presence indicator can show offline while the gateway works normally, so health checks should look at outputs and heartbeats, not presence. Second, the gateway will drop eventually, on a network blip or an update, and the recovery move is mechanical: restart the service and verify the workspace responds. Section 5.3 covers the failure in detail. The wiring itself is the easy part. The monitoring of it is the job.
4.7 Backup and the reapply ritual
The maintenance reality of this pattern is the maintenance cliff from the essay: the day you stop paying a vendor, you become the vendor. There is no support ticket for a home board. What replaces the vendor is a calendar with two standing items.
The first item is backup. The whole operation, every profile directory, is a set of files plus a state database. Back up the profile tree on a schedule to a destination that survives the board, and encrypt anything that leaves the machine, because the tree contains secrets files. Test the restore, not just the backup. A backup that has never been restored is a hope, and the essay's vocabulary applies: verify, do not trust the self-report of the backup script.
The second item is the reapply ritual. Updates to the agent runtime and its dependencies arrive on their own schedule, and an update can drop a local patch, change an output shape, or reset a behavior the operation depends on. The ritual has three steps, run after every update: reapply the local patches from a recorded list, verify the services come back in order (gateway first, then the site, then the cron fleet), and watch the first scheduled job complete before calling the update done. On this system the proof of an update is a morning brief that lands on time the next day. Until that lands, the update is not finished.
The backup calendar and the update calendar are the two dates that make the machine boring. A boring machine is the goal. The interesting failures, the ones that take a morning, are the ones this paper has already named and the ones section 5 catalogs with their containment rules.
5. What breaks
A paper that only shows the wiring would be a sales document. This system runs, and it also breaks, in a short list of predictable ways. Each failure mode below is stated with the rule that contains it. The essay vocabulary applies here unchanged: the maintenance cliff, the verification gap, shadow IT, data gravity, and liability all show up in a harness of six profiles on one board, plus a set of operator-specific failures that only appear once the thing runs for months.
5.1 The maintenance cliff: updates drop local patches
The runtime and its dependencies update on their own schedule. An update can overwrite a local patch, change the shape of an output, or quietly alter a behavior the operation depended on. There is no vendor pager. The containment is the reapply ritual from section 4.7, on a calendar: reapply recorded patches, bring services back in order, and do not call the update done until the first scheduled job completes after it. Own the machine on a calendar, or the machine owns your mornings.
5.2 The verification gap: exit 0 is not done
An agent will report success with total confidence and be wrong. The error hides in the exception path, the edge case, the row that does not fit the rule. The containment is verification discipline (section 3.5) plus the naming of a reviewer (section 6): outputs get checked against reality, JSON gets parsed, links get fetched, images get rendered, and consequential artifacts have a reviewer who is not the agent that produced them. Generation outruns review. The fix is to make review a step, not a hope.
5.3 The day the gateway drops
The workspace connection is a process, and processes die. When the gateway drops, work pauses and presence can show offline, though the reverse is also true and more dangerous: presence can show offline while the gateway works. The containment is knowing the difference. Health checks watch heartbeats and outputs, not the green dot. Recovery is mechanical: restart the service, verify the workspace responds, and confirm the next scheduled job lands. The rule: monitor the thing you depend on by its outputs, and keep the restart one command away.
5.4 Keys expire and rate limits hit
Model keys expire, providers change terms, and rate limits arrive mid-run as HTTP 401s and 429s. The containment is visibility: auth failures go to the error log, the error log is read first in the maintenance ritual, and key rotation sits on the ops calendar with the other recurring dates. When a key dies, the failure presents as a 401, and the fix is a rotation, not a retry. Keep one list of which key serves which profile, and keep that list in the ops profile, not in a human's inbox.
5.5 Context bleed when jobs multiply
The fleet grows because jobs work. Thirty-nine enabled jobs means thirty-nine prompts, and the temptation is to let each one carry more context, mention more history, or reach into more state. That is how contexts bloat, costs rise, and jobs start stepping on each other. The containment is the dispatch discipline from section 3.3, applied to cron: every job prompt is self-contained, points at the record instead of carrying it, and names what it is allowed to touch. When a job needs history, it reads the record. When it stops fitting that shape, rewrite the prompt, do not widen the context.
5.6 Cost creep when nobody watches
The cheap-by-default pattern only stays cheap if somebody checks. Spend creeps when a job's model gets bumped, a retry loop spins, or a digest grows past its budget and nobody notices for a week. The containment is the cost digest, a scheduled job that reports spend on a regular cadence into the workspace where a human sees it. Money is a metric like any other: it needs a reporter, a channel, and a reader. The cost digest is that reporter, and the morning read is the reader.
5.7 Stale dashboards and silent reporters
Everything in this system is produced by something, and when a producer pauses, its outputs go stale while looking normal. A dashboard that stopped updating last Tuesday still renders. The containment is to make silence visible: every recurring report names its feeder, and the fleet includes a job that flags missing heartbeats and stale outputs, so a paused reporter becomes a named item in a digest instead of a quiet lie. If a report can go stale unnoticed, it will.
5.8 Shadow IT: the second tool you did not map
The essay names the failure: one working tool becomes a template, and by spring three teams have three unversioned copies with private logins. The one-company version is smaller and faster: a stray script with its own credentials, a second chat workspace for a side experiment, a local file of tokens that nobody listed. The containment is the same rule at any scale: build in the open, and make visibility cheaper than secrecy. Everything runs under a profile in the council, every profile is in the backup, and a tool that cannot be seen by the operator does not exist. The unmapped estate is where the quiet disasters live, and at this size the estate is mappable in an afternoon. Keep it that way.
5.9 Data gravity: the second system of record
The workspace is the operating record, and it is a good one, but it is not the system of record for the company's actual data. Payroll numbers live in the payroll platform. Financial data lives in the financial accounts. When an agent copies that data into its own store for convenience, the company has bought a second system of record and a lifetime of keeping two versions of reality in agreement. The divergence is where the quiet errors live. The containment is the first of the two rules in section 6: decide where data lives, and keep the system of record authoritative. Agents read from it, write results to the workspace and the files, and never quietly accumulate a private copy of the truth.
5.10 Liability: do not build what you cannot defend
The essay's rule holds at this scale with extra force, because a home board has no SLA and no vendor to sue. Payroll, compliance, and anything where the answer to who is accountable has to be a contract stay with vendors. The harness builds on the workflow layer around those systems: briefings, digests, watches, drafts. And because the machine does produce consequential output, the trail matters: sessions are logged, job executions are recorded, and the workspace keeps the record of what was asked and what came back. If you cannot show the trail for a decision, you cannot defend the decision, and at this scale you are the one who will have to.
6. The two rules
Set two rules before the first profile is created, and write them where everyone can see them, because they are the containment for most of section 5.
Rule one: where data lives. Name the system of record for every kind of data the operation touches. The workspace is the operating record. The payroll platform holds payroll. The financial accounts hold money. The repositories hold code. Agents read from the record and write results back to the workspace and the filesystem, and no agent maintains a private second copy of anything that matters. When a new kind of data appears, the first question is where it lives, asked before anyone builds anything that touches it.
Rule two: who reviews output. Name the reviewer for every class of output, and make sure the reviewer is not the agent that produced it. For briefings and digests, a human reads them in the workspace every morning, which is review by attendance. For content that goes public, a human signs it before it ships. For code and configuration, a second pass verifies against reality: exit codes, rendered artifacts, running processes. A self-report of done is a claim, and claims get checked.
Both rules have the same shape: they name a thing and a person, in writing, before the work happens. The data store and the reviewer are decided on day one, or they get decided after an incident, and that meeting costs more than the machine did. Everything else in this operation is schedule: the backup date, the update date, the cost digest, the morning read. A calendar with names on it is the whole management layer.
7. Appendix
7.1 File map: one profile directory
This is the real tree of one profile on the running system, with the secrets file listed but not shown. The five other profiles mirror the same shape under their own names. Comments in parentheses describe roles; nothing here is a secret.
~/.hermes/profiles/press-1/
|-- .env (secrets file: keys and tokens, never shown)
|-- SOUL.md (identity: who this profile is)
|-- config.yaml (model, provider, skills, approvals)
|-- profile.yaml (profile description)
|-- assets/
| `-- avatar.png (profile avatar)
|-- cache/ (model catalog and tool discovery caches)
|-- cron/
| |-- executions.db (job execution history)
| |-- .jobs.lock (scheduler lock files)
| `-- ticker_heartbeat (scheduler health marks)
|-- logs/
| |-- agent.log
| |-- errors.log (read first in the maintenance ritual)
| `-- gui.log
|-- memories/
| |-- MEMORY.md (profile notes)
| `-- USER.md (facts about the user)
|-- runtime/
| `-- active_sessions.json
|-- sessions/ (session transcripts, searchable)
|-- skills/
| `-- <category>/
| `-- <skill-name>/
| `-- SKILL.md (plus optional reference files)
|-- state.db (session and state database)
`-- projects.db (project records)
Two notes. First, config.yaml backups appear alongside the file with names like config.yaml.bak-
7.2 Roster
The council in the September 2026 snapshot. One Director and five specialists.
- director-1: the Director. Routes work, runs the cron fleet, and synthesizes results. The only profile wired to the chat gateway as the primary operator of the workspace.
- researcher-1: research and evidence gathering. Sourced findings with citations.
- dev-3: software development. Code, repositories, and deployments.
- pixel: design. Visual identity and image work.
- ops-5: operations. Schedules, monitors, and the machine itself.
- press-1: content. Essays, whitepapers, listings, and social copy.
7.3 Job list sample
Sixty-one jobs on file, thirty-nine enabled. A representative sample of the enabled fleet, with names as they appear in the scheduler:
- Morning Brief, daily 8AM: the day's digest into the workspace.
- Cost Digest, daily: spend reported on a cadence so nobody watches it alone.
- Payroll News, daily refresh: news relevant to the payroll stack.
- Paylocity Inbox Daily Report: inbox activity pulled on a schedule.
- Omi Memory Digest: a two-hour summary posted to the memories channel.
- Market watchers: continuous watches over the markets the operation tracks.
- Resolution trackers: follow-ups that close when their subject resolves.
- Race arms for scheduled economic releases: separate jobs that read NFP, CPI, and FOMC releases as they land, so the brief reflects the news instead of the schedule.
Each job follows the anatomy in section 4.5: id, name, prompt, schedule, skills, model, and a delivery target. The job list is the company's pulse, and like a pulse it is worth checking on a schedule of its own: jobs that fail silently are the ones section 5.7 says to make visible.
7.4 Cost notes
The operation runs on consumer API pricing because it is engineered to: small models for ordinary work, larger models only for the tasks that need them, scripts instead of agents where no judgment is required, and a cost digest that reports spend into the workspace every morning so the number is seen by a human on a cadence. The lesson is not that this stack is cheap, though it is, relative to a GPU box. The lesson is that cost is a metric, and a metric needs a reporter and a reader. The moment the cost digest stops running, spend stops being watched, and section 5.6 starts. Watch the digest the way you watch the morning brief: as a scheduled fact, not an occasional curiosity.
Closing
If you build one of these, or you tried to and it broke, I would like to hear about it: [email protected]. The essay that argues the case this paper demonstrates is Nobody Buys Software Anymore. They Describe It., and the companion that names the failure modes is You Built It. Now You Own It. This paper is the third piece: the machine, in the open, with its scars shown on purpose.