Problem
I got tired of explaining the same things about myself to each new agent. Preferences, background, working style, recurring tasks, tools, constraints. Repeating all of that every time was tedious and made the workflows less useful than they should have been.
But I also did not want to solve that by telling every agent everything about me. A writing agent does not need the same context as an event-planning agent or a golf agent. I wanted a better pattern than either re-explaining myself from scratch or dumping my whole life into every workflow.
Product Approach
Personal Agent OS starts with one idea: there should be a human-reviewed source of truth about me, but every agent should only receive the subset that is relevant to its job. A writing agent should know different things than an event-planning agent. A newsletter agent should know different things than a golf coach.
In practice, it is a least-privilege pattern for AI workflows. The system is built around canonical source files, generated context for specific tools and agents, and an inbox for proposed durable updates. It works like a hub-and-spoke model: the reviewed source of truth stays at the center, while each agent operates with its own scoped context and can suggest changes back to the hub instead of quietly becoming its own competing memory system.
How It Works
1
Canonical source
Human-reviewed files hold the durable version of identity, preferences, work style, tools, and sensitive-exclusion rules.
2
Context packaging
Build scripts generate tool-specific and agent-specific context so each workspace starts with the right slice of information.
3
Scoped agents
Specialized agents for email digest, golf coaching, meal planning, event planning, and product leadership coaching operate with explicit scope and exclusions.
4
Inbox proposals
When an agent notices a durable change, it sends a proposal back to the hub instead of editing the source of truth directly.
What I Learned
The most useful shift was realizing that context is a governance problem, not just a memory problem. It is not enough to ask whether an agent remembers something. You also have to ask whether it should know it, whether it can act on it safely, and how a durable update becomes part of the system.
This is also where I started to see that colloquial language and tool access are different things. An agent may technically have access to a capability and still fail unless the affordance is made explicit enough for that model to operationalize it.
Where It Could Go
The next step would be a more shareable version that uses fake sample context instead of real personal details, shows more clearly what each agent received, and makes the handoff between agents easier to inspect. I would also like to pressure-test the same system with more formal orchestration and evaluation tooling so it is easier to compare agent behavior across models and workflows.