Found something good?

This is a complete A–Z breakdown of Kimi K3 what it is and how to run your entire business using only AI Agents

This will change everything about how you work with Kimi

TLDR; If you don't want to read a 4480-word article, here is the GitHub repo which you can give to your agent. https://github.com/codejunkie99/meridian-company-os Bookmark these builds before you forget.

Preface

The elements every company OS needs, derived from scratch, with the prompts that build each one. Learn the principle, take the prompt, build yours.

I built one (meridian-company-os, MIT licensed) and it is the reference for this guide, not the point of it. The point is the nine elements underneath it, because those are the elements underneath any company OS you will ever build.

Bookmark these 9 builds before you forget.

The Command cockpit: the operator surface from BUILD 5, and what the nine elements add up to.

Introduction

You are orchestrating agents with a chat window and a prayer. An agent that can spend money, ship code, and hire other agents is a company, and you are running that company with the tooling of a search box. This guide fixes that.

Here is the situation as of July 2026. A coding agent on the worker tier will generate any file you can describe in one paragraph, in under a minute, for cents.

It will also happily spend your budget, resolve its own approvals, and forget everything on refresh, because nobody built the walls. The model got cheap. The operating structure around it did not get built.

A company OS is not a nicer chat UI. It is the answer to six questions, at all times:

Answer all six and you have a company OS. Answer fewer and you have a demo.

This is not a philosophy of one, and it is not a walkthrough of my repo. It is the required elements, each with a generalized prompt you hand your coding agent, the reference implementation it produced for me, and a check that proves the element exists.

My stack was React 19 + TypeScript + Vite. Yours can be anything. The elements do not change.

How the whole thing was actually built, so you can copy the method and not just the output:

That is the entire toolchain. You will see it working inside every build below.

What you will have at the end, element by element:

Who this is for: anyone with a terminal, a coding agent, and the intent to run more than one agent at a time. You do not copy my files. You take the principle and the prompt, and your agent writes your files.

How to read it: in order, doing the checks. Each element assumes the ones before it. The check is the proof the element exists; skip it and you are stacking on rumor.

The principles underneath everything. Three, and every design decision in the next nine builds is an instance of one of them:

No essays from here on.

Prerequisites

Pin the runtime once: Kimi K3 is the worker tier that generated the reference files. Run a different model and you get different files, which is fine, because you are building yours, not mine. What you hold constant is the prompt and the check.

Why Kimi K3

Kimi K3 at a glance: launch specs and public benchmark standings, styled to match the console.

The runtime choice, fast. Not hype, just the tradeoffs.

What it is

Where it loses (be honest)

Where it wins (this exact workload)

Why it's the pick

The map

The nine elements, and the files they became in the reference implementation. Your file names will differ. Your elements will not.

All ten prompts in this guide also ship as runnable files in prompts/, one per element, so kimi -p "$(cat prompts/00-scaffold.md)" works out of the box.

First, the scaffold. Principle: fewer dependencies, fewer lies. A company OS's one job is trustworthy state, and every dependency is someone else's state you now have to trust.

Prompt, through kimi -p:

What K3 produced for the reference: React 19 + TypeScript 5.8 strict + Vite 6, and exactly one runtime dependency beyond React (lucide-react for icons). Scripts: dev, build (tsc -b && vite build), preview.

Context7 mattered here already: without it, K3 scaffolded React 18 patterns; with it, the config came out Vite 6 native on the first try.

CHECK: install and typecheck, exit code 0. Count your runtime dependencies; if you cannot justify each one in one line, this build is not done.

BUILD 0: The vocabulary

Why, in one line: a company is state, so before any behavior exists, every noun the company runs on must have exactly one typed definition.

First principles. Ask what irreducibly exists in any company of humans and agents, and you get seven nouns:

Every company OS is these seven nouns plus opinions. Type the nouns first and the opinions stay honest.

The generalized prompt. Notice it names the nouns and the two questions to ask of each, and nothing about my stack:

Reference implementation. K3 emitted src/lib/types.ts, 416 lines, zero logic. The shapes that carry the whole system, and the enforcement question visible inside each one:

How the Kimi pass went: one kimi -p call, whole file in one shot.

The Superpowers skill earned its slot here. Its review discipline made K3 append a "two of your nouns overlap" note: a delegation and a task assignment were nearly the same noun, resolved as a delegatedBy field on Task instead of a new interface. That is the prompt's last sentence doing real work.

CHECK: typecheck passes with zero any. Then the noun audit: grep your interfaces and confirm each of the seven nouns has exactly one home.

BUILD 1: The world

Why, in one line: you cannot learn to operate an empty company, so the OS must boot into a world already mid-operation.

First principles. An operator surface teaches through recognition: you see an over-budget agent, a blocked task, a pending hire, and you learn what the controls do. An empty state teaches nothing, and it hides rendering bugs besides (an empty column and a broken column look identical).

So any company OS needs a deterministic seeded world: same world every boot, every status represented, every gate already holding a decision.

The generalized prompt:

Reference implementation. K3 produced two files.

seed.ts (~600 lines of fixtures):

And skills.ts, a registry of installable capability packs credited to their real sources:

There is a loop worth noticing. The two skills running inside my Kimi Code CLI while it generated this file are the first two entries in the registry the file defines.

The OS you are building installs skills on its agents the same way you just installed skills on the agent building it. The method is the product.

One regeneration was needed here. K3's first pass put every task in in_progress, which fails the "every status at least once" line. The fix was not editing the seed; it was that line getting added to the prompt, then kimi -p again. Fix the prompt, never the file.

CHECK: boot twice, diff the world. Deterministic means identical.

BUILD 2: The source of truth

Why, in one line: a company is state, so state may only change in one place, and everything else is a window.

First principles. The failure mode of every multi-agent dashboard is the same: five components each holding a copy of the truth, drifting. The cure is structural, not disciplinary.

One store. One reducer, a pure function from state plus action to state. Views read; views dispatch; views never mutate.

Do this and every later element (the log, the gate, the heartbeat) becomes a reducer case instead of an architecture decision.

The generalized prompt:

Reference implementation. src/lib/store.tsx, about 1,400 lines: StoreProvider, useStore() returning { state, dispatch }, a reducer covering every member of the Action union, and selectors (companyAgents, companyTasks, companyApprovals, agentName). The case that carries principle two and three at once:

How the Kimi pass went: this is the one build K3 stalled on. Two worker-tier attempts produced reducers that mutated nested objects in three cases, both caught by the check, not by reading the diff. The build got escalated to a frontier model, same prompt verbatim, clean on the first pass.

That is the tiering rule in practice: K3 is the default worker, the frontier model is reserved for the one build where purity is the whole point. Asked for the case it would bet money I break first, it named deciding an already-decided approval, hence the status !== "pending" guard.

CHECK: exhaustiveness by grep. Every action in the union has a case, or it is a dead button waiting to be pressed.

BUILD 3: The heartbeat

Why, in one line: real companies move while you are not looking, so the OS must tick on its own clock or it is training you on a lie.

First principles. Agents spend and progress continuously; your attention is discrete. A console that only changes when you click teaches you that nothing happens between clicks, which is exactly wrong and exactly expensive.

So any company OS needs a heartbeat: a small, bounded, pure state transition fired on a timer. Bounded is the load-bearing word. An unbounded tick is a runaway; a bounded one costs pennies of simulated spend and proves the pipes.

The generalized prompt:

Reference implementation. src/lib/sim.ts: runTick(state): State, fired every 2,600 ms by a single interval in the provider. Per tick: one working agent accrues $0.40 to $3.04, one open task gains 3 to 10 percent progress, a heartbeat line lands, and the log is capped at 500 entries newest-first.

Asked to defend the numbers, K3's answer survives as the design: a tick just visible to a human eye (2.6s), spend small enough that an hour of simulation costs pocket change, a log cap so memory cannot creep.

And exactly one interval, wired by a follow-up kimi -p edit scoped to a single hook: while simRunning, dispatch {type:"tick"} every TICK_MS, clear on cleanup, intervals nowhere else.

CHECK: watch the feed for 30 seconds; lines land roughly every 2.6s. Pause; it freezes. Resume; it moves. Lines arriving faster than 2.6s means two intervals, and two intervals means some component is doing the provider's job.

BUILD 4: The memory

Why, in one line: a company that forgets itself on refresh is a demo, and the line between demo and system is a reload.

First principles. Split all state into two kinds and the design writes itself. Domain state (who works here, what was spent, what was decided) is the company; it must survive. Session state (which screen you were on, an open modal, a toast) is your visit; persisting it is a bug.

So: an allowlist snapshot of domain slices, written on a debounce after real edits, restored on boot. And one ordering law: never write before the restore completes, or you overwrite the company with a blank.

The generalized prompt:

Reference implementation. A hydrate action, a persistable() allowlist (companies, agents, goals, tasks, approvals, runs, activity, customSkills, activeCompanyId), a 400 ms debounced write, and the trap named in the prompt guarded by one line:

How the Kimi pass went: a kimi -p edit against the existing store, not a fresh file. The prompt's warning clause is why the hydrated gate exists.

Asked to name the trap before stepping in it, K3 named this exact race: first render fires the persist effect before the snapshot loads, writing seed over saved data. Cheap models find real bugs when the prompt makes finding bugs the deliverable.

CHECK: two states, both reachable. Let the sim burn for 20 seconds, refresh, numbers continue. Clear the key, refresh, clean seed returns.

BUILD 5: The operator surface

Why, in one line: the operator asks three questions in a fixed order (what is happening, does it need me, what do I do), and the main screen must answer them top to bottom.

First principles. Derive the cockpit from the questions, not from what looks good in a screenshot:

And because a company is state, every widget is a pure read of the store. A cockpit that caches its own numbers is an instrument that lies.

The generalized prompt:

Reference implementation. A sidebar shell (nav, company switcher, sim toggle) and CommandView: north-star with delta, risk radar, pending-approvals count that deep-links to the gate, department burn bars from company.budgets, newest-20 activity feed. All selectors, no local intervals, machine values in mono.

Context7 earned its keep again: React 19 memoization guidance came in current, so per-tick re-renders stay cheap without stale-API workarounds.

The cockpit is one operator surface; the Work board is another, built from the same store and the same tokens. Once BUILD 2 exists, every surface is a pure window onto it.

CHECK: open the cockpit cold and answer the three questions aloud in under ten seconds without clicking. Switch companies; every widget swaps with no stale number bleeding through. Click the approvals count; you land on the gate.

BUILD 6: The gate

Why, in one line: power flows through gates, so nothing that spends, hires, ships, or fires resolves without an explicit recorded yes.

First principles. Autonomy is a budget, not a right. The five verbs that can hurt you (spend, hire, override, publish, terminate) each need the same four things at decision time:

One more, easy to miss: when a policy check fails, approving must feel like overriding. Defaults are where governance goes to die.

The generalized prompt:

The gate. Every card shows the ask, the requester, the rationale, the amount, and the system's own policy checks. Approve and reject are the only exits, and both write to the log.

Reference implementation. ApprovalsView: pending first, each card with type badge, requester, rationale, amount in mono, and pass/fail policy checks with detail text. The default-flipping line, exactly as the prompt demanded:

The decision itself is BUILD 2's decideApproval case, which is the point: the gate is a screen, but the law lives in the reducer. A gate enforced in the UI is a suggestion.

CHECK: approve one seeded item; it moves to decided, stamped "approved by you," and a governance line lands in the feed. Find an item with a failing check; the button reads "Override and approve."

Then watch the sim for a minute: if any approval resolves without your click, the gate is broken and nothing else matters until it is fixed.

BUILD 7: The command line

Why, in one line: operators issue orders, and an order that costs a model call to parse is slower, pricier, and less deterministic than a regex.

First principles. There are two kinds of operator utterances. Commands ("create task x, assign to bea, p1", "move MER-1042 to review", "budget report") have fixed grammar and a known action: parse them locally, dispatch the real store action, print exactly what changed. Total cost zero, latency zero.

Everything else is conversation, and that is what the model is for. The routing rule is deterministic first, model as fallback, and always show the trace. An OS that does things silently is indistinguishable from one that does nothing.

The generalized prompt:

Typed commands hit the store directly and print the trace, no model call. Only a non-command sentence falls through to the local K3 runtime, shown here answering with its `kimi -p (local, k3)` trace.

Reference implementation.

KimiSpaceView: regex parse against the command grammar, name-to-id resolution through the store's selectors, dispatch, trace line back into the chat. The fallback branch prints a placeholder this build, because the model is BUILD 8's problem:

CHECK: create task: refresh onboarding emails, assign to Bea, p1 creates a real task with a generated code and prints the trace. budget report prints spend against limit per department, instantly, no spinner, because no model was called. A nonsense sentence hits the placeholder.

Command handling that shows a loading state is a model call you are paying for and should not be.

BUILD 8: The real runtime

Why, in three lines: everything so far runs on a simulation, and a company OS that never touches a real agent is a diorama. The last element is the bridge to an actual runtime, and it is the most dangerous file in the system, because it spawns a process that can think and spend.

So the fence is the feature: concurrency of one, an input cap, a kill timer, an isolated workdir, and credentials that never cross back over the wire.

First principles. Whatever your runtime (a CLI, an API, a queue), the bridge needs the same five walls, each answering one attack:

And one grace rule: if the runtime is absent, degrade to simulation, never crash. The console must outlive its agents.

The generalized prompt:

Reference implementation. Kimi is both the builder and the built here: the runtime the bridge spawns is the same ~/.kimi-code/bin/kimi that generated every file above, invoked as kimi -p with the operator's message on stdin, reusing the kimi login credentials.

The fence, as shipped:

Two endpoints: GET /local-runtime/status and POST /local-runtime/kimi/chat. And because the bridge spawns a local process, the dev server binds to 127.0.0.1 only:

A final kimi -p edit swapped BUILD 7's placeholder branch for the real POST, with the offline fallback intact.

CHECK: prove the fence, not the feature. Status endpoint reports the CLI; a non-command sentence gets answered by the real model. Then attack it: two chats at once, the second returns 409; paste 9,000 characters, rejected before spawn; rename the CLI binary, the app stays up in sim mode.

The rollout

An OS you built in a weekend still gets adopted in weeks. Graduate.

Week 4 is where the numbers stop being simulated. Department burn, projections, and a model/token ledger, every real dollar traceable to an agent and a task.

Each row unlocks the next. Week 4 on day 1 is how you fund a educational invoice.

The runbook

Every alarm the system raises, and the move. The signal is generic to any company OS; the action is where the reference points you.

The Rules (print this)

Closing

The repo was never the point. Meridian is one implementation, in one stack, of nine elements that do not care about your stack: vocabulary, world, truth, heartbeat, memory, surface, gate, command line, runtime.

Build those nine in Rails or Rust or a spreadsheet with macros and you have a company OS. Skip the gate or the log and you have a leak with a UI, in any language.

And notice what actually built it: a worker-tier model, two skills, nine prompts, and a check after each. The method you just read is the machine it produces. You write the spec, a cheap agent writes the files, the walls keep everyone honest, including you.

Tonight: write BUILD 0. Open your agent, hand it the vocabulary prompt, and make it name the seven nouns of your company. Do not let it write a single behavior. The nouns are the whole first night, and everything else is a window onto them.

So here is the question worth arguing about: what are the seven nouns of your company, and which two did you almost merge? Build BUILD 0 tonight and reply with your types.

Built from my own notes while constructing the reference repo; every file was generated by Kimi K3 through the Kimi Code CLI, and a frontier model edited this prose and handled one escalated build (the reducer). The claims are checkable against (https://github.com/codejunkie99/meridian-company-os).

This is written by the authors' notes while building with Kimi K3 and Kimi Code CLI and it has been edited by Kimi K3 Code and Opus 4.7.