{"id":"2089684614055068043","url":"https://x.com/Av1dlive/status/2089684614055068043","text":"https://x.com/i/article/2089582272521613312","author":{"name":"Avid","username":"Av1dlive","avatarUrl":"https://pbs.twimg.com/profile_images/2010392290590912512/x7vtAe5W_200x200.jpg"},"createdAt":"Tue Aug 18 12:03:31 +0000 2026","engagement":{"replies":23,"retweets":36,"likes":235,"views":690618},"article":{"title":"how to build a one-person company using Kimi K3","previewText":"i wrote the A-Z blueprint for building an AI-native company with agents...\nnot another swarm of bots... a system that decides what work matters, what agents may do, and what they must leave behind.\n\n ","coverImageUrl":"https://pbs.twimg.com/media/HQDCE_cbIAAsnXR.jpg","content":"i wrote the A-Z blueprint for building an AI-native company with agents...\n\nnot another swarm of bots... a system that decides what work matters, what agents may do, and what they must leave behind.\n\ncore insight: harness will determine how ai-native companies allot compute. for this experiment Kimi K3 works as the central intelligence unit which powers the entire ai-native company foundry \n\n> TLDR: If you don't want to read the 4,800 words in this article, you can just go to this https://github.com/codejunkie99/company-foundry.\n\na company is not a group of agents. it is the method that tells them what work matters, what they may do, and what they must leave behind.\n\ni do not want an AI CEO.\n\ni want work to enter once, find the right context and model, follow a known method, stay inside clear limits, and leave an artifact the next person can trust.\n\nThat is a much less dramatic idea. It is also much more useful.\n\n# the wrong starting point\n\nMost teams build the visible AI before the company: a chat window, coding agent, research agent, tool access, and a folder of prompts. Then they call it a team.\n\nThen the work starts to matter.\n\nThe questions become operational:\n\n- Where did this customer claim come from?\n\n- Why did this task use the most expensive model?\n\n- Who gave the worker access to a customer system?\n\n- Which instructions produced this dashboard?\n\n- Can someone repeat the result without reading the entire chat history?\n\n- What happens to company knowledge when the model changes?\n\nThe usual answer is more chat: another prompt, another bot, another dashboard, and another person who knows where the important context lives.\n\n## activity is not an organisation\n\nThat creates activity. It does not create an organisation.\n\n→ the model is rented\n\n→ the agent is replaceable\n\n→ the operating method is owned\n\nThis is the project I want to build: Company Foundry.\n\nCompany Foundry takes a real company brief and compiles it into an operating method. Its first native target is DeepSeek Harness.\n\nIt creates the context, skills, routes, policies, packets, evidence records, artifacts, and operating surface as one coherent system.\n\n## prove one workflow first\n\nThe first version does not need to run an entire company. It needs to make one important workflow real.\n\nFor example: customer evidence becomes a product decision brief, with sources, named assumptions, an approved model route, and a visible artifact.\n\nThat is the starting line for an AI-native company.\n\n# the thing we are actually building\n\nThe product is not a new agent team.\n\nIt is not a prompt library with a nicer interface. It is not a control plane bolted onto DeepSeek Harness. It is not a dashboard that watches agents work.\n\nIt is a compiler for organisational method.\n\n## compile the company once\n\nSomeone describes the company once: product, customers, goals, sources, systems, permissions, budgets, rules, and current work.\n\nThe compiler turns that description into a portable company specification, then generates the files and runtime configuration a harness can use.\n\nThe universal output looks like this:\n\nThis is deliberately boring. It does not try to model every meeting, person, or feeling in a business.\n\nIt records the parts that make work reproducible: purpose, ownership, evidence, authority, output, and review.\n\n![](https://pbs.twimg.com/media/HP-wOQ_acAAWFK1.jpg)\n\n## contracts make the folder useful\n\nFor DeepSeek Harness, the compiler produces a company preset and a set of plugins:\n\nThe folder is not the product. The contracts inside it are.\n\nOne contract defines ownership, another task admission, another source policy, and another model eligibility.\n\nThe final contracts decide whether a result may leave the company and how that result is measured.\n\nmake models replaceable\n\nThis matters because every AI company will use more than one model.\n\nKimi K3 can handle the first build. It can turn a company brief into an initial working harness, reason over a scoped work packet, create code and artifacts, and help refine the method.\n\nBut the company should never assume that one model stays best forever. The harness owns the company method. The router selects the worker.\n\n# why an agent is not a company\n\nAn agent is good at a turn of work.\n\nIt can read a task, inspect context, call tools, make a plan, write code, research a question, or create a draft.\n\nThat is valuable. It still does not have a company purpose, budget, permission boundary, or durable record of why a decision was made.\n\nA company has to survive the end of a session.\n\n## sessions end. companies continue.\n\nThe durable layer has four jobs:\n\n- Remember what customers said without treating generated summaries as fact.\n\n- Record whether a decision came from evidence, an inference, or a guess.\n\n- Match model cost and capability to the consequence of the task.\n\n- Stop a worker from acting externally merely because it has the tool.\n\nA company has a method.\n\nThe method needs a stable shape:\n\nEvery arrow is a place where work can become unclear.\n\n## every arrow is a failure boundary\n\n- A vague goal makes workers optimise the wrong thing.\n\n- Uncontrolled context leaks sensitive or irrelevant information into a run.\n\n- Hand-copied skills let two workers use different methods without saying so.\n\n- A hidden route makes cost and quality impossible to explain.\n\n- An artifact without evidence turns a fluent guess into company memory.\n\nThis is what makes the word *harness* useful.\n\nA harness is the layer that gives agent work shape. It composes the available capabilities, creates scoped context, runs work, records what happened, and exposes the same truth through different surfaces.\n\nThe company layer adds two questions above the usual agent loop:\n\n→ can this worker do the task?\n\n→ should the company do this work, with this evidence, under these limits, at this cost?\n\nThat question should not live inside a giant system prompt.\n\n![](https://pbs.twimg.com/media/HP-wcywbUAAEcnH.jpg)\n\n# start with a company brief, not an agent prompt\n\nThe first input to Company Foundry is a company brief.\n\nThis is not a brand document. It is not a long founder memo. It is a structured description of what the company needs the harness to know in order to operate safely and usefully.\n\nThe smallest useful brief contains six things.\n\n- Identity. What does the company sell, who is it for, and what should a worker never assume?\n\n- Goals. Which outcomes are active now, and which ideas are merely interesting?\n\n- Evidence. Which sources are approved, reliable, current, and accessible for this work?\n\n- Authority. What may a worker observe, prepare, change, or send?\n\n- Resources. Which repos, apps, tools, models, and data stores exist, and what do they cost?\n\n- Standards. What must a finished artifact contain, and which claims or changes require review?\n\nThe company brief must remain separate from the model conversation.\n\nKimi K3 can turn loose company notes into a structured first pass and expose missing constraints. The result belongs in company configuration, never in one agent’s chat history.\n\n## prompt 01: compile the company before you create workers\n\nGive Kimi K3 the raw company notes and make it expose the missing decisions:\n\nKimi K3 is not deciding what the company is. It is compiling what the company has actually decided.\n\nThat makes it inspectable. It also makes it replaceable.\n\n- When a customer segment changes, update the company profile.\n\n- When a source is no longer approved, update the source policy.\n\n- When model economics change, update the model registry.\n\nThe next relevant packet receives the new rule without rewriting every worker prompt.\n\n![](https://pbs.twimg.com/media/HP-wjv6aoAARJgR.jpg)\n\n→ prompts describe a moment\n\n→ company records describe a method\n\n→ a harness applies the method to the moment\n\n# the first principle: work must leave a trace\n\nThe dangerous part of agent work is not that a model can write.\n\nThe dangerous part is that it can change things outside itself.\n\nIt can create a record, open a pull request, update a dashboard, post a message, spend money, or contact a customer.\n\nThese are not merely tool calls. They are emissions from the company into the outside world.\n\nThe harness should make a hard distinction between four levels of authority.\n\n## four levels of authority\n\n- Observe: inspect approved information, documents, repositories, or dashboards.\n\n- Prepare: create a private candidate artifact, draft, branch, or dashboard definition.\n\n- Commit: change company state through a reviewed record or operation.\n\n- Emit: send information or trigger an action outside the company boundary.\n\nObserve and prepare can be broad. Commit and emit need explicit limits.\n\nThis is not bureaucracy. It is how you make fast work reversible.\n\nAn agent should be able to explore several approaches inside an isolated scope. It should be able to produce drafts, candidate code, and retries without creating permanent debris.\n\nBut the company needs a clear point where the work becomes real.\n\nBefore an external effect, the system stores its target, intended change, evidence, actor, approval rule, and compensation path. The effect stays proposed until the gate clears it.\n\n## the effect becomes real at the gate\n\nAn email can be drafted many times. Sending it is one event.\n\nA pull request can be prepared many times. Merging it is one event.\n\nA research brief can be rewritten many times. Using it to change the product roadmap is one decision.\n\nThis gives the company a simple safety rule:\n\n→ explore freely inside the work scope\n\n→ commit deliberately to company state\n\n→ emit externally only through a visible gate\n\nThe model does not decide its own authority. The work packet and policy do. That is what turns a tool-using agent into automation the company can trust.\n\n# DeepSeek Harness is where the company becomes executable\n\nDeepSeek Harness is a good first native target because it is designed around composition.\n\nModels, tools, persistence, policy, interfaces, and agent behavior are separate capabilities.\n\nEach capability has a stable definition, a provider, and named consumers. That makes the system flexible without making it vague.\n\nDeepSeek Harness hands the company four rules worth copying:\n\n1. A capability is a declared service with a stable contract.\n\n1. A provider implements it while consumers depend on the contract.\n\n1. A gate blocks admission until required services exist, while a lock orders withdrawal and cleanup.\n\n1. A state mutation returns its inverse so the change can be rolled back and traced.\n\nCompany Foundry should add company capabilities in the same way.\n\n- company-profile resolves identity, rules, source policy, and scoped context.\n\n- company-router selects an eligible model and records why it was chosen.\n\n- company-skills loads a versioned method with its templates, tools, and checks.\n\n- company-evidence records sources, extracts, claims, confidence, and review state.\n\n- company-artifacts creates durable outputs with provenance.\n\n- company-dashboard projects packets, approvals, routes, costs, artifacts, and failures.\n\n## prompt 02: turn the company contract into DeepSeek Harness capabilities\n\nThe second prompt crosses the boundary from organisational design into executable infrastructure:\n\nThis is the point where a prompt becomes engineering work. The output must contain seams, failure behavior, and tests, not a picture of an architecture.\n\nThe key is that these are capabilities, not special instructions for one role.\n\nThe capability boundary changes three things:\n\n- Customer research becomes a service any approved workflow can use.\n\n- Model routing becomes policy applied before work begins.\n\n- Every artifact receives a path, type, owner, inputs, status, and review record.\n\n![](https://pbs.twimg.com/media/HP-xEiSa8AA5jI4.jpg)\n\none packet gets one boundary\n\nThe harness also creates a useful boundary around a session.\n\nOne work packet gets only the skills, sources, tools, route, and permissions it needs. A research task does not receive deployment access. A coding task does not receive customer data by default.\n\nThe task remains resumable because its model-visible context and meaningful events are recorded with the run.\n\nThe user interface is only one surface on that system.\n\nEvery surface should show the same company truth, whether it is a command line, dashboard, review queue, or app.\n\n# customer research is the first real company skill\n\nThe most useful early workflow is customer research.\n\nIt connects directly to product, sales, support, and strategy. It is easy to make impressive-looking but unreliable. It forces the company to define sources, evidence, claims, review, artifacts, and decision boundaries.\n\nThat makes it the right test.\n\nDo not start with the request “research our customers.” Start with a work packet:\n\nNow the work has a shape.\n\n## prompt 03: run research as a bounded swarm\n\nOne model can execute the packet sequentially. A swarm can split it without splitting the truth.\n\nThe collectors run in parallel because they share a schema, not a memory.\n\nThe synthesizer receives the ledger instead of four conversations. The reviewer receives the claims and evidence instead of the other workers’ confidence.\n\nA swarm is a temporary execution shape. It is not the organisation chart.\n\nthe ledger is the shared memory\n\n1. Discover: list the segments, unknowns, product terms, competitors, and evidence gaps.\n\n1. Collect: record each source with an ID, type, location, date, access state, and excerpts.\n\n1. Synthesize: separate what the company knows, infers, and still needs to learn.\n\n1. Review: reject unsupported claims, scope leaks, and recommendations that outrun the evidence.\n\nThe finished artifact should contain more than polished prose. It should contain a source ledger, a claim table, open questions, recommended next actions, the skill version, the route record, and the review status.\n\nThat artifact can then become input to a product skill.\n\n![](https://pbs.twimg.com/media/HP-w8MObMAA3SZa.jpg)\n\nThe product skill consumes the approved brief instead of researching the question again. It can create a problem map, identify product bets, prepare a specification, and record the decision.\n\nA coding skill can then consume the approved specification and prepare an isolated implementation plan or pull request.\n\nThis is how the company accumulates a method rather than a pile of generated documents.\n\n# skills are not prompts. they are company methods.\n\nA skill file is useful. It is not enough.\n\nA company skill needs an identity, a version, an owner, an allowed scope, required inputs, expected artifacts, authority boundaries, tools, source rules, and an evaluation.\n\nFor a customer-research skill, the contract might say:\n\nThis is much more portable than a giant role prompt.\n\nThe same skill can run through Kimi K3 today, another model tomorrow, or a different agent runtime later. The underlying instructions may change because models behave differently. The company contract stays stable.\n\n## the registry makes the method operable\n\nSkills should live in a registry, not in a random folder.\n\nThe registry answers which version created an artifact, which skills can use sensitive data, and which methods can create a pull request.\n\nIt also shows who owns each output, which artifacts depend on a changed skill, and which evaluation is failing.\n\nThere are two useful families in the first registry.\n\n- Company skills produce insight briefs, account plans, decision memos, market maps, operating reviews, and dashboards.\n\n- Build skills produce code plans, repository maps, pull requests, tests, app prototypes, design implementations, and release notes.\n\nBoth families follow the same contract. The difference is the capability they require and the authority they may receive.\n\n## prompt 04: write the skill registry and the skill files together\n\nDo not ask Kimi K3 for a list of clever agent roles. Ask for executable methods:\n\nCompany Foundry can compile these definitions into native skill files and presets. Kimi K3 can help author them. DeepSeek Harness can load and run them. The registry remains the company’s source of truth.\n\n![](https://pbs.twimg.com/media/HP-xLocbcAAXSSf.jpg)\n\nThis is where Kimi K3 is valuable in the first build. It can create a code skill, inspect a repository, produce a scoped implementation plan, and generate an artifact inside the harness.\n\nBut it should run under a defined packet with a named scope, route record, and evaluation. It should never receive “improve the product” plus a collection of production credentials.\n\nThe output of a good skill is not just text. It is a repeatable work method with a visible result.\n\n![](https://pbs.twimg.com/media/HP-0wxbakAAX3HP.jpg)\n\n# route models like a company spends money\n\nA model picker is for a person.\n\nA model router is for a company.\n\nThe router receives task requirements before the run starts. It knows whether the task needs low cost, low latency, large context, tool use, computer use, structured output, code generation, or high-quality synthesis.\n\nIt filters out ineligible models, then chooses from the remaining routes according to company policy.\n\nThe first policy can be small:\n\n## prompt 05: make the router earn every expensive call\n\nThe router should be designed against real packets before it is trusted with live work:\n\nIn a swarm, this decision happens per worker. Extraction can use an economy route while synthesis uses a capable route. Parallel work should not multiply premium-model spend by accident.\n\nKimi K3 can sit in the capable tier where its quality is useful. That is not a permanent claim about every task.\n\nThe router should use company evaluations, cost, availability, and task requirements to choose the route.\n\nthe receipt is the debugging surface\n\nEvery route needs a receipt:\n\nThe company can now answer why a cost occurred before the invoice arrives.\n\nIt can also learn. If the output was weak, inspect the packet, source set, skill version, selected route, model result, and evaluation. Do not reduce the diagnosis to “AI was wrong.”\n\nThe router owns trade-offs. The agent owns the task.\n\nThat division prevents a common failure: every agent asks for the strongest model because the agent has no reason to care about cost, latency, or company-wide capacity.\n\n![](https://pbs.twimg.com/media/HP-xQ47bsAA03Em.jpg)\n\n# the Company Room is the proof\n\nThe first user experience should be a Company Room, not a fantasy dashboard with animated agents.\n\nA working room where a person can ask one important company question and see the system turn it into accountable work.\n\nFor example:\n\nThe room should expose the whole run:\n\n- packet, owner, context, and source set\n\n- skill version, model route, and authority level\n\n- work log, evidence, artifact, cost, and pending approval\n\nThis makes the harness legible.\n\n## the room reads records, not reasoning\n\n- A leader can see whether the system is producing useful work.\n\n- An operator can see why a run is waiting.\n\n- A reviewer can inspect the artifact and its evidence.\n\n- An engineer can trace the dashboard to the skill, route, and inputs.\n\nThe room borrows a normalised event stream so different providers can expose work without leaking their private formats into the interface.\n\nIt also borrows a permission broker with a strict default: when the permission service is unavailable, the risky action stops.\n\nThe rule is simple: a pending ask resolves to deny when the broker disappears. With no answerer, the caller does not guess. The caller stops.\n\nThe Company Room should borrow the pattern, not the product shape.\n\nThe core is responsibilities, packets, authority, artifacts, evidence, and evaluations. Workers bind to roles for a task, runtimes execute it, and the company record keeps the durable method.\n\n## prompt 06: generate the dashboard from the run record\n\nThis is where Kimi K3 can turn the same contracts into a usable app artifact:\n\nThe prompt forces the interface to reveal the work without becoming a second source of truth.\n\nThe interface is generated from company truth, which means it can be regenerated when the workflow changes. The dashboard is a projection of the harness, not another place to store the company.\n\n![](https://pbs.twimg.com/media/HP-yFH2aYAAsVmB.jpg)\n\n# where the planes fit\n\nNo single framework needs to own the whole company.\n\nThese are design assignments, not sourced facts. Each plane owns one question and nothing else.\n\n1. Control plane: goals, budgets, approvals, work status, ownership, and audit.\n\n1. Runtime plane: worker identity, execution environment, task state, and events.\n\n1. Composition plane: DeepSeek Harness assembles context, tools, skills, routes, policy, sessions, and artifacts.\n\n1. Compiler: Company Foundry turns the portable company specification into the files each plane needs.\n\nThe DeepSeek Harness target receives presets, plugins, skill files, policy, evaluations, and profile patches. The other planes receive the goals, budgets, roles, approvals, tasks, and audit records they own.\n\nA new harness receives an implementation specification instead of being forced into a fake integration.\n\nThe company should not be trapped in a user interface. That is the whole point.\n\n![](https://pbs.twimg.com/media/HP-yA0GbQAAhkab.jpg)\n\n# build the smallest company before you build the company\n\nThe first release should not create departments, autonomous executives, or dozens of skills.\n\nBuild one closed loop.\n\nMake that loop work end to end.\n\nThe first loop must prove five things:\n\n- The brief came from a real company description.\n\n- The source list contains approved data.\n\n- The artifact is useful enough to support a decision.\n\n- The review finds real issues and the route is logged.\n\n- The dashboard shows actual state rather than imagined activity.\n\n## expand only after proof\n\nThen add the next loop: decision brief to product specification, followed by specification to isolated code plan and reviewed pull request.\n\nEach loop adds a skill, artifact type, authority boundary, and evaluation only when the company needs it.\n\nThis keeps the system flexible because it keeps it small.\n\n![](https://pbs.twimg.com/media/HP-x7F4bQAAoyny.jpg)\n\n![](https://pbs.twimg.com/media/HP-1HOHbEAA3BTG.jpg)\n\n# one company, several workers\n\nThe six prompts above can run in one Kimi K3 session while the first company is small.\n\nOnce the loop is stable, the same files can drive a swarm.\n\nCompany Foundry opens the packet, DeepSeek Harness assembles capabilities, the router selects each worker, and every worker writes to the same artifact contract.\n\nYou can also package a specialist worker around another model. A Claude-based coding worker can receive one repository packet, one code skill, an isolated work scope, and a required test artifact.\n\nThe useful part of the Grokbot pattern is the packaged worker with its own tool loop. The company layer still owns its memory, permissions, budget, and handoff.\n\n## prompt 07: create a specialist without creating a fake employee\n\nThat gives you the useful version of an agent swarm. The workers can differ. The company method does not.\n\nRun it in this order:\n\n1. Compile the company brief.\n\n1. Generate the DeepSeek Harness capabilities.\n\n1. Write one skill and its evaluation.\n\n1. Run one packet with one worker.\n\n1. Add parallel workers only where the artifacts can be merged safely.\n\n1. Generate the Company Room from the run ledger.\n\n1. Promote a result only through a written review gate.\n\nThe first milestone is not an autonomous company. It is one reviewable loop that can change workers without losing its memory.\n\nthe asset that survives\n\nAn AI-native company is not a company with the most agents. It is a company whose work can move through models and tools without losing purpose, evidence, authority, or memory.\n\nBut the company should own the thing underneath all of them.\n\nthe real asset is not the agent.\n\nit is the method the company can run again tomorrow.\n\nConclusion: this has been inspired by Deepseek Harness and the everything is a plugin thesis. Edited using Kimi K3 and written by Typeless."}}