What worked, what failed, what it costs, and what I learned building five always-on AI-agent lanes for markets, an Executive MBA, family logistics, household administration, and operations.
I’m a fixed-income portfolio manager, a part-time Wharton Executive MBA student, and a dad managing several very different streams of information and obligations at once.
Instead of building one giant assistant, I built a small fleet of specialised agents with deliberately separate contexts:
- 💼 Work — public-market research, central banks, ratings, new issues and market monitoring
- 🎓 MBA — coursework, deadlines, class preparation and study support
- 👨👩👧 Family — school, calendars, bills and household logistics
- 🧾 Admin — captures, classifies and files household paperwork
- 🛟 Ops — watches the other lanes, checks freshness and failures, auto-fixes safe mechanical problems and escalates the rest
Today the system contains 80+ scheduled workflows across five lanes. Most are deliberately boring scripts rather than AI calls. The goal is not maximum autonomy; it is reliable, low-noise assistance with clear boundaries.
This repository is not a product or a clone-and-run template. It is a 26-chapter field guide to the architecture, costs, failures, evals, privacy boundaries, examples and operating lessons from using the system in daily life.
Professional-data boundary: the work lane is a personal research system using public or personally subscribed information. It is not connected to employer inboxes, internal research, portfolio positions, client information, non-public information, order-management systems or trading systems. See 24 · What the agents can and cannot see.
emails calendars news/RSS documents
\ | | /
\ | | /
▼ ▼ ▼ ▼
┌─────────────────────────────────────────────────────────┐
│ FOUR CONTENT LANES │
│ │
│ 💼 WORK 🎓 MBA 👨👩👧 FAMILY 🧾 ADMIN │
└─────────────────────────────────────────────────────────┘
▲
│ safe auto-fixes / health signals
▼
┌──────────────┐
│ 🛟 OPS LANE │
│ watches all │
└──────────────┘
│
▼
📱 short Telegram messages
only when useful
Each lane has its own job description, memory, credentials, data sources and delivery channel. Context isolation is a feature, not an inconvenience. A school newsletter should never appear in a market brief; a bond-spread move should never pollute family memory.
| Lane | Role | Watches | Example output |
|---|---|---|---|
💼 Work (em) |
Public-markets research chief-of-staff | Financial press, central banks, rating agencies, bond-market feeds, research, podcasts | “Morning brief: 10y +6bp overnight; one rating action crosses an index boundary; a large new issue prices today.” |
🎓 MBA (wemba) |
EMBA study partner | Coursework, university email, class calendar, Canvas | “Case due Thu; these new materials map to your scaling-operations paper.” |
👨👩👧 Family (family) |
Household logistics assistant | School email, newsletters, family calendar, bills | “Sports day Friday; permission slip due Wednesday.” |
🧾 Admin (tax) |
Household filing clerk | Personal inbox attachments and a filing destination | “Filed 3 documents; 1 sent to review because ownership was ambiguous.” |
🛟 Ops (ops) |
On-call SRE for the fleet | Jobs, feeds, services, freshness and failures | “Repaired a torn login token; everything else green.” |
Everything reaches me through separate Telegram bots, and the system is designed to stay silent when there is nothing worth saying.
Real screenshots live in images/screenshots/.
The most useful numbers are not vanity metrics, so I keep current scale separate from the date-stamped operating snapshot.
- 80+ scheduled workflows across five lanes, plus a handful of plain system-timer helpers
- Four content lanes + one supervisory ops lane
- A 26-chapter public field guide
- Regression tests, corrections ledgers, freshness checks and lane audits around the model calls
At the time of the measured snapshot, the fleet was smaller: 62 scheduled jobs. That month:
| Metric | Measured result |
|---|---|
| Scheduled jobs | 62 |
| Scheduled executions | ~266/day (~8,000 over 30 days) |
| Jobs calling an LLM | 10 (16%) |
| Pure-script jobs | 52 (84%) |
| Latest run successful | 61/62; the remaining job had not reached its first scheduled fire |
| Escalations opened | 60 |
| Escalations closed | 56 |
| API-account spend | ~$85 / 30 days* |
| Labelled regression evals | 27 |
*The API account also supported a few unrelated experiments, so this is an upper bound, not a clean fleet-only cost number.
The full methodology and the metrics I still do not measure are in 23 · The fleet by the numbers.
Most of a useful “AI agent system” should not be AI.
In the measured snapshot, 84% of scheduled jobs were deterministic software. Scripts poll feeds, compare timestamps, reconcile ledgers, move files and check health. LLMs are reserved for tasks where language understanding, synthesis or judgment actually adds value.
That design is cheaper, easier to test and easier to trust.
A few patterns have held up particularly well:
- Specialise the contexts. One large assistant accumulates irrelevant context; narrow lanes stay legible.
- Use deterministic software for plumbing. Polling, filing, timestamps and invariants do not need an LLM.
- Make silence the default. A successful run with nothing useful to say should send nothing.
- Treat the model as a junior assistant. It can triage, synthesise and draft; consequential decisions still belong to a human.
- Separate orchestration from intelligence. The fleet mostly runs on a boring clock. The intelligence lives inside individual jobs.
- Monitor freshness, not just exit codes. A pipeline can return
successwhile quietly serving stale or incomplete information.
The failures taught me more than the successful demos. Among them:
- an agent confidently invented a tool that did not exist
- a workflow “succeeded” repeatedly while producing useless output
- a fallback model had a smaller context window and broke an end-of-day flow
- concurrent processes corrupted shared authentication state
- stale data and fuzzy matching produced false confidence even though jobs returned successful exit codes
- a privacy scrubber was imported but not actually called on one execution path
- persistent memory was overwritten by another process
- an LMS sync silently went stale for days
Those failures changed the architecture. The project gradually became less about making models smarter and more about building evals, explicit data boundaries, freshness checks, corrections, deterministic guardrails and safe recovery around them.
Read 11 · When it goes wrong, 21 · Evals as tripwires and 25 · The corrections loop.
“The job ran successfully” does not mean “the system was right.”
The hardest part of living with agents is not getting them to produce an answer. It is knowing when they are stale, silently wrong, over-confident or operating outside the boundary you intended.
That is why the fleet now includes labelled regression evals, source checks, completion ledgers, freshness monitoring, lane audits, corrections that the model cannot rewrite, and an ops lane whose job is simply to watch the rest.
The most valuable agent is often the boring one watching the clever ones.
The full guide is 26 chapters. The complete index is in docs/.
| Featured chapter | Why read it |
|---|---|
| 01 · What is an agent? | Plain-English explanation of an agent vs. a chatbot |
| 05 · Design principles | Cost control, silence-by-default and failure handling |
| 06 · The schedule | The live job map and orchestration |
| 08 · The fleet map | The whole architecture at a glance |
| 10 · What it costs | The honest money page |
| 11 · When it goes wrong | Real failures and how they were caught |
| 21 · Evals as tripwires | Why successful exit codes were not enough |
| 22 · The queue that learns my taste | Explicit human feedback instead of guessing preferences |
| 23 · The fleet by the numbers | Date-stamped operating metrics |
| 24 · What the agents can and cannot see | Data and professional boundaries |
| 25 · The corrections loop | Corrections the model cannot silently rewrite |
| 26 · The filing clerk | The newest lane and its testing lessons |
- New to agents: 01 → 03 → 04 → 12
- Interested in architecture: 02 → 08 → 09 → 05
- Thinking of building one: 07 → 05 → 10 →
examples/
- This is a personal setup, not a product. It is shared to explain a way of working, not as something to clone and trust blindly. Secrets, tokens and personal data have been removed.
- It costs real money. The agents call commercial AI APIs. Cost is controlled by keeping most plumbing deterministic and routing models deliberately; see 10 · What it costs.
- The AI is not an oracle. Every design choice assumes it will occasionally be wrong.
- Context stays put. Lanes do not casually share personas, credentials or raw data. Cross-lane sharing is deliberate and limited; see 04 · Memory and 24 · Data boundaries.
- The measurements are intentionally imperfect. Where the fleet does not track something, the docs say so instead of manufacturing a number.
Built on Hermes Agent, with Telegram delivery, local memory, scheduled jobs and a mix of language models routed by cost and task. The fleet runs on a small cloud server.
Several sanitised excerpts of the real implementation are in examples/, and some run without credentials or setup.
- 📖 Read the full 26-chapter field guide
- 🧪 Explore the sanitised examples
- 🛠️ Read how I built it
- 🔒 Review the data boundaries
Built and documented collaboratively with Claude (Anthropic). The architecture described here is real and used in daily life.