Days 1–16: From Personal Context to an Agentic Operating System

4d • Wins

I have just completed Days 1–16 of the Zero One Systems curriculum. My contribution has been applying the prompts provided each day to my own work, challenging the assumptions where they did not fit, and following the process far enough to see what emerged.

For my use case, a personal agent is not simply a chatbot that remembers you. It is an operator-facing manager backed by explicit context, bounded authority, specialist systems, and evidence.

That is the claim this post is trying to earn.

I began with a personal dashboard and a simple question: what would an AI need to know about me to become genuinely useful?

The curriculum works through personality, values, goals, risk tolerance, and decision-making. The most useful—and uncomfortable—exercise was a documentary-style interview covering my background, career change, failures, family, money, and what actually drives me.

That became soul.md: a private canonical file describing how I think and operate. I then distilled it into soul.runtime.md, a smaller set of executable principles for practical agent use. Two of those principles have already changed the architecture:

Autonomy requires bounded authority, which exposed the weakness in my original agent design.
Correctness governs speed, which is why completion evidence now belongs in an append-only
Decision and Evidence Ledger rather than being reduced to a status flag.

One lesson mattered more than the rest:

More context is not automatically better. Stable identity, current project state, private history, operational knowledge, and evidence are different classes of information. They update at different rates and should only be exposed to agents that genuinely need them.

The biggest change came when I reviewed which agent to build first. My initial choice was a Founder Intelligence Scout—monitoring AI tools, GitHub repositories, contracting opportunities, and founder tactics. After two separate research workflows, the problem became obvious. I already had specialised systems doing adjacent work:

Career Master
CallScore
Market Structure Lab
thredOS
Hermes
RuleIQ
Helios

A Scout would have been another worker adding information to a portfolio that nobody was actually coordinating. The gap was not intelligence gathering. It was that nothing could tell me what mattered most across the systems I already had. So the Scout became a later subordinate capability, and the primary agent design became the Omar OS Portfolio Orchestrator.

Its job is to answer:

What matters most now?
Which system owns it?
Is that system genuinely ready, blocked, stale, or contradicted?
What can proceed autonomously?
What requires my decision?
What evidence proves completion?

It coordinates the portfolio without absorbing the business logic or authority of the specialist systems.

The first five knowledge bases planned beneath it are:

Goals and Priorities
System and Project Registry
Capability, Authority, and Routing Map
Relationships and Commitments
Decision and Evidence Ledger

There is plenty left to build, but Days 1–16 gave the system a much stronger foundation than I expected from what initially appeared to be a series of reflection exercises.

Credit to Lewis

@Lewis Jackson

and the Zero One team for designing a process that gradually exposes the architecture underneath.