Yodu.ai

AI employees that remember the work — and keep it moving.

Comment

Inspiration

Sam Altman has talked about the first one-person billion-dollar company. I kept getting stuck on a practical question: even a one-person company still needs a company around that person. It needs people who own support, sales, research, finance, content, operations, and engineering—and it needs a way to manage them. What if those employees were AI employees?

For the last five months, I have been testing that idea inside a real business. API.market is currently at $130K ARR, and I have been running parts of it with 18 AI agents powered by OpenClaw on a cloud VM. Discord gave every agent a channel. Another agent synchronized work into Trello. Different employees had their own inboxes, LinkedIn access, and the tools required for their jobs.

The agents worked. They helped with customer support, outreach, investor follow-up, research, content, fundraising work, new customers, and even the work that got me invited onto a podcast.

But the company around them did not exist. Memory and files were scattered across the VM. Tools and credentials were difficult to manage. I could not see the complete work. The runtime was fragile. I could not safely give the system to another founder or even reproduce it cleanly for another person on my team.

That is why I built Yodu.ai.

What we built

Yodu is a managed operating environment for AI employees. It takes the setup I had assembled by hand and turns it into a product a founder can actually operate.

Every employee can have a role, identity, company context, role-specific memory, durable files, skills, tools, schedules, tasks, deliverables, model access, and explicit limits on what they may do without a human. A Company Architect continuously learns the business and maintains sourced company knowledge. A Chief of Staff turns that knowledge into coordinated work. Specialist employees execute inside the access and autonomy the owner grants them.

Memory is deliberately split into two layers. Six governed company documents hold shared truth—profile, business plan, metrics, capability plan, open questions, and decisions—with provenance, versions, and organization scope. Each employee also has a private OpenClaw working memory with full-text and embedding-based retrieval. Before every turn, Yodu injects current company truth and relevant open work, so an employee can recall useful history without confusing private notes with canonical company facts.

The management system is split too. The Company Architect maintains strategy and shared context; the Chief of Staff converts it into priorities, delegation, and follow-through; an optional Ops Lead reviews execution evidence one employee at a time; fact-checking and reliability employees provide independent assurance. Health checks can detect missing runtime configuration and perform bounded repairs, while credentials, permissions, and consequential external actions remain under human control.

From the web command center or Expo mobile app, the owner can talk with employees, inspect work, move tasks, read files, manage memory, connect tools, review schedules, approve risky actions, watch runtime health, repair a workspace, and switch between multiple companies without mixing their data.

Yodu is not another chatbot. It is the management and infrastructure layer around agents that keep working after a conversation ends.

The most important Build Week insight was that visibility still was not enough. Eighteen agents can produce an enormous amount of activity without necessarily moving the company toward the right outcome. AI employees need the operating discipline of a real organization: objectives, measurable targets, short cycles, ownership, evidence, review, and a way to learn when a tactic is not working.

That became Yodu's Company OS. Its verified backend foundation connects objectives to key results, initiatives, 72-hour operating cycles, employee and team targets, role scorecards, evidence, independent reviews, accepted outcomes, metric movement, experiments, retrospectives, and learning history. The complete cockpit and structured meeting experience are still in progress, so we describe them as the next product layer rather than pretending they are already finished.

How the system works

Yodu has a control plane and an execution plane.

The control plane is a multi-tenant TypeScript platform built with Next.js, React, Expo, oRPC, Better Auth, PostgreSQL, Prisma, object storage, and Stripe. It owns organization boundaries, employee configuration, company memory, files, task state, schedules, approvals, tool policies, encrypted secrets, billing truth, runtime health, and the operating graph.

The execution plane runs an isolated OpenClaw environment for each company. Yodu compiles employee identities and operating files, sends commands through a workspace-scoped queue, and runs agent turns through a sidecar worker. OpenClaw owns the active sessions, local memory indexes, scheduled execution, and generated artifacts. Messages, task changes, files, evidence, approval requests, health, usage, and run state flow back into Yodu.

Company memory is stored in PostgreSQL as governed, inspectable documents. The same canonical context is compiled into each employee's runtime on every turn, while agent-local memory is indexed in SQLite using full-text search and text-embedding-3-small vectors. A bounded, redacted workspace snapshot lets the Company Architect propose updates without turning every file or message into company truth. New facts need provenance; unanswered questions stay visibly unknown.

Tools can come from Composio, native integrations, or authenticated custom MCP servers. Access is controlled per employee. Secrets are encrypted and never displayed again. Runtime ports remain private. External URLs pass through safety checks. Risky sends, posts, spending, deletion, and other side effects pause for a time-bounded human decision. Decisions and results become durable audit evidence, and retries are designed to be idempotent rather than duplicating work.

How Codex and GPT-5.6 were used

Codex was not just autocomplete for this project. It was the collaborator I used to turn the original VM setup into a product architecture, inspect the existing system, compare implementation choices, write and review code, run tests, diagnose runtime failures, and harden security boundaries.

During Build Week, Codex helped choose Expo for the mobile companion, translate the supervision workflow into mobile navigation and shared API contracts, implement authenticated product flows, identify an approval-scope vulnerability, debug CI and dependency races, inspect the real OpenClaw protocol, and verify native and production builds. The repository contains the dated designs, implementation plans, tests, and before/after commit boundary.

GPT-5.6 is also part of the product. A user can authorize a ChatGPT subscription through device authentication, and an isolated sidecar exposes the available GPT-5.6 models to that company's OpenClaw runtime. We live-validated authentication, model discovery, streaming and non-streaming responses, tool calls, and multi-turn conversations.

Yodu also exposes its own scoped MCP server, which means Codex and other authorized clients can configure employees, memory, schedules, tasks, tools, and company context without bypassing Yodu's organization, permission, or approval boundaries.

What changed during Build Week

  • Built the Expo companion for overview, employee conversations, activity, search, tasks, files, inbox, approvals, notifications, settings, and workspace switching.
  • Added the Company Architect discovery loop with bounded workspace snapshots, sourced canonical memory, open questions, and capability planning.
  • Connected ChatGPT subscription authentication and GPT-5.6 model routing to isolated OpenClaw runtimes.
  • Expanded the platform MCP surface for employee, schedule, tool-access, memory, and Company OS operations.
  • Added custom MCP OAuth, multiple protected headers, per-employee tool visibility, and safer approval scopes.
  • Hardened runtime provisioning, repair, teardown, queue idempotency, file synchronization, configuration drift detection, health evidence, and backup visibility.
  • Implemented the verified Company OS backend foundation for goals, cycles, targets, scorecards, reviews, outcomes, metrics, Stripe revenue truth, experiments, attribution, and learning.

Yodu existed before the event, so the repository documents the boundary explicitly: 6861cee1 is the last pre-period commit and 2844ba5e is the first qualifying commit after July 13, 2026 at 9:00 AM Pacific.

Challenges

The difficult part was never making an agent produce text. The difficult part was making an independent runtime behave like a trustworthy employee inside a multi-tenant product.

We had to preserve strict workspace boundaries across web, mobile, API, MCP, storage, notifications, and OpenClaw. We had to keep files and memory durable without turning duplicated runtime state into the source of truth. We had to prevent an agent-authored risk label from expanding an approval. We had to recover from partial failure without repeating commands.

We also had to turn a setup that previously required a hand-maintained VM, OpenClaw configuration, model credentials, tool wiring, and manual repair into a repeatable product flow. Yodu still has real installation complexity behind the scenes, but the product now provisions and monitors that runtime while keeping ports private and secrets encrypted. And we had to route a user's own model subscription into an isolated container without exposing the subscription or collapsing tenant boundaries.

Codex was especially useful here because it could inspect the entire system, challenge assumptions, construct focused tests, and follow failures across UI, API, database, worker, runtime, and infrastructure boundaries.

What we learned

An AI employee needs more than a prompt. It needs a company around it: a job, context, memory, tools, files, work, evidence, deadlines, authority, and a manager who can see when something is blocked.

We also learned that activity is not progress. Messages, tasks, files, and tokens are operational signals; they are not business outcomes. The system becomes genuinely useful when every employee can explain which company objective the work serves, what evidence proves completion, what metric should move, and what the team will change if it does not.

Finally, human approval and observability are not administrative extras. Once agents can act through real company accounts, those controls are the product.

What's next

Next we are completing the Company Cockpit: visual goals, roadmaps, target health, workforce scorecards, structured standups, sprint planning and review, retrospectives, an operating calendar, decision routing, and an AI moderator that prepares meetings from real evidence instead of producing another generic summary.

We are also developing controlled coding sidecars so authorized engineering employees can delegate bounded implementation work to Codex or Claude Code with streamed progress, isolated workspaces, and human tool approvals.

The long-term goal is simple: give one ambitious person the operating leverage of a capable company without losing memory, control, evidence, or the ability to understand what is actually happening.

Built With

Share this project:

Updates

posted an update —

A request to the judges. This is an active and live system, and it is actually constantly creating PRs and doing a bunch of things, so I request that you please review this prior. It actually already found paying users that it wants to onboard.

Log in or sign up for Devpost to join the conversation.