The interesting part of an agent platform is the guardrails

I run a personal operating system built out of AI agents. Twenty of them, each a scheduled or on-demand automation: a job scout that scans boards at 7 AM, a morning brief, an expense tracker for my consulting LLC, a financial pulse, a special-education case manager for my family, a resume studio, a career coach that reviews the search every Monday. It runs on Claude Code. I designed it and I operate it.

The point of this post is not the agents. Anyone can wire a language model to a cron line. The point is everything around them: the parts that keep a fleet of agents from silently dying at 7 AM, or worse, confidently telling me something that is not true. That work is not prompt engineering. It is the same production discipline you would apply to any system you actually depend on, and it is where all the real engineering lives.

Treat every scheduled agent as a service that will fail. A raw cron line tells you nothing when a run dies. It fires into the dark and you find out three days later that your morning brief has been empty since Tuesday. So nothing runs raw. Every scheduled agent is wrapped in a runner that timestamps start and end, captures the exit code, and appends one line per run to a health ledger. The ledger is a dead man's switch: if an agent should have run and there is no line, I know a silent failure happened. The runner retries transient failures with a backoff, but it deliberately does not retry a usage-cap refusal, because a short back-off cannot clear a rate window and blind retries just burn the budget. Last week the whole morning stack got eaten when the machine was asleep on battery. The ledger is how I caught it, and a watchdog now covers that specific gap. You do not get that from a cron line. You get it from deciding, up front, that the thing will fail and building the place where the failure shows up.

Run two runtimes on purpose. When I am sitting in the loop, the agents reach Notion, Gmail, and Calendar through hosted connectors. Those connectors do not attach to a headless run at 7 AM when no one is logged in. Instead of pretending one integration path covers both worlds, I run two. Interactive sessions use the connectors. Scheduled runs use thin direct-API clients I wrote for the same services. Same data, two doors, because the environment is genuinely different and one door does not fit both. Most integration pain comes from refusing to admit that the logged-in case and the unattended case are not the same problem.

Make the system correct itself, not just run. The knowledge behind all of this is a plain-text wiki the agents maintain: one topic per page, cross-linked, with an index and an append-only log. When an agent learns something, it writes it down, so the next session starts smarter instead of starting over. The same idea covers failure. When an integration call breaks, the fix goes into an error log, and the next run checks that log before repeating the mistake. A system that only runs will make the same wrong call every morning forever. A system that corrects itself pays for the debugging once.

Build the guardrail against your own tools. The most important rule in the whole platform exists because an early version embarrassed me. It drafted a resume bullet with a metric I had never hit. It was not malicious, it was a language model doing what they do: filling a plausible gap with a confident number. So now anything headed for a public surface gets audited against ground-truth source files first, and any claim the sources do not support gets cut, not softened. Not reworded to sound safer. Cut. An agent that will fabricate is worse than no agent, because it launders a guess into something that looks verified. If you are building on top of these models and you have not built the thing that stops them from making things up, you have not finished.

Decide what never leaves the machine. Not every workflow should be maximally connected. The money agent and the family agent are fully local by design: no cloud database, no dollar figure or child's detail on any shared surface, the whole tree kept off any remote. Other agents can read a direction ("runway is tight") but never a number. That boundary is not a limitation I worked around. It is a design decision I made on purpose, and choosing where it sits is part of the architecture, not an afterthought to it.

The agents are the easy part. The reliability ledger, the two runtimes, the self-correcting knowledge base, the fabrication guard, the local-only walls: that is the platform, and that is the work. It is the same discipline as running any production system. Assume it will fail and build where the failure shows. Separate the cases that are actually different. Close the loop so debugging compounds. Guard the output against your own tools. Draw the boundary on purpose. The model is the new part. Almost everything that makes it trustworthy is not.