The question
Could agents share responsibility for product direction instead of waiting for the next instruction?
Building an AI Organization That Could Move Without Me
I built Operator to test whether AI agents could interpret a product vision, choose useful work, and keep a portfolio moving without a new prompt between every step.
Founder, product designer, and system architect · 2026-present · Agentic product development, Scrum, GitHub, Supabase, automation
At a glance
The first failure
My original governance model made agents cautious, approval-dependent, and reluctant to act.
The proof point
A real customer opportunity became a prioritized project, working demo, timeline, and prepared meeting.
I was still the missing step
I regularly use AI to turn ideas into working products. The pattern was productive but repetitive: describe the next task, let an agent complete it, review the result, and tell it what to do next. The agents could perform much of the work, but I remained the connective tissue between every step.
The problem became obvious while I was exploring a website-services business. An agent could research a company, create tickets, build a site, prepare a demo, and improve the result. Yet none of those abilities mattered unless I kept returning to restart the process.
Could I give agents a product vision and an operating environment, then return to useful, coherent progress rather than another request for instructions?
TODO_ASSET: Operator portfolio overview
Show the portfolio view, active projects, agent roles, and the work moving between them without exposing private customer data.
The first organization was afraid to act
I modeled Operator after a product organization. A portfolio-level Product Owner decides which opportunities deserve attention. Each project has its own Product Owner and backlog, while developer and QA agents own progress toward the product goal. GitHub stores the public work, and Supabase supports private operational data and telemetry.
The structure made sense, but my first authority model did not. I had designed extensive safeguards around the assumption that a human should review nearly every meaningful action. Agents learned that the safest response was to report a blocker, request approval, and wait.
I had built a system for initiative whose rules rewarded passivity. More orchestration did not create more ownership. It removed the judgment that made the experiment worthwhile.
TODO_ASSET: Operator organization diagram
Show the founder, portfolio Product Owner, project Product Owners, developer and QA agents, GitHub work, and Supabase telemetry in one simplified diagram.
I changed what ownership meant
The redesign started with a simpler principle: responsibility is not real without enough authority to act. I reduced the normal operating rules to three boundaries.
Own the outcome
Agents can choose useful work, create tickets, make reversible decisions, and continue when the original plan is incomplete.
Escalate protected risk
Spending money, contacting customers, adding unfamiliar services, and other protected actions still move upward for human judgment.
Prove the thesis first
Interesting infrastructure waits until it helps agents create a tested, observable increment toward a real product outcome.
This distinction let authorized work continue while the smallest risky decision was escalated. It also forced me to separate brainstorming from validated direction. Operator became less about recreating every Scrum ceremony and more about preserving goals, ownership, feedback, and clear decision boundaries.
A customer opportunity became the test
The first convincing test came from a real prospective customer. I gave Operator the available business context but did not prescribe every deliverable. The portfolio Product Owner recognized that the opportunity offered clearer external value than several internal experiments and shifted attention toward it.
Over the following days, the opportunity became a dedicated project with a repository and backlog. Agents researched the business, produced a working website demo, created a timeline, prepared the meeting, organized supporting business and legal material, and surfaced the few decisions that still required my authority.
Operator did not run the engagement without me. The meaningful result was narrower: I could provide an opportunity and a direction, step away, and return to a coherent body of work rather than a system waiting for the next prompt.
TODO_ASSET: customer opportunity timeline
Create a sanitized sequence from initial context to prioritization, project setup, demo, meeting preparation, and founder approval.
What it proved, and what it did not
Operator is still an active experiment, not a claim of full autonomy. Its results depend on clear goals, reliable tools, observable evidence, and human judgment around first-time or high-risk actions. Different projects still vary in how consistently they produce useful work, and external outcomes remain the most important test.
The project has changed how I think about product ownership. I still own the code, the risks, and the final outcome, but agents can contribute more than implementation. They can interpret goals, notice missing work, make bounded decisions, and help shape direction when the environment gives them meaningful responsibility.
My current thesis is that the next challenge in agentic development is not tighter control of every action. It is designing an environment with clear philosophy, appropriate authority, useful feedback, and tools that make good work observable. Operator is my attempt to learn where that model works, where it fails, and which decisions should remain human.