# How to Build an AI-Native Startup
**作者**: cyber•Fund
**日期**: 2026-05-25T16:36:16.000Z
**来源**: [https://x.com/cyberfund/status/2058950286324986294](https://x.com/cyberfund/status/2058950286324986294)
---
A practical guide for founders going from zero to AI-native: map the work, build the context, write the evals, run the loop.
By Stepan Gershuni, @cyntro_py
Read this article on the cyber.fund blog
It's 9am at two startups in the same market, founded the same month. At company one, the ops lead is still working through old support tickets, the analyst is rebuilding last week's dashboard, and the founder is on a standup about a customer call nobody's been able to resolve. Everyone is scrambling to fix yesterday’s problems and the product is stagnating.
At the second company, all of that happened overnight. Agents triaged the tickets, refreshed the dashboard, surfaced the churn risk buried in the call. The founder has already fixed the problem and is iterating on the product with his team.
Yes, founders will spend their time differently in an AI-native startup, but that’s not the fundamental change. The fundamental change is how fast the company can learn, iterate, and evolve. The second company will outlearn the first every single day. Over weeks, this will compound leverage. Over months and years, only one will succeed.
The company is AI-native when its operating model changes: fewer people coordinate less, agents execute more of the repeat work, and humans focus on direction, taste, relationships, validation, and accountability.
For founders looking to build or rebuild their companies into this new reality, it can seem like a daunting task. But it doesn’t have to be. Building AI-native starts with a few steps that when iterated upon recursively will completely reorganize the way your company operates.
It goes a little something like this:
- Map the work
- Build the context system
- Choose the simplest automation that works for each piece
- Turn repeated work into skills
- Write evals that decide whether the work is good
- Run the company loop on a weekly improvement rhythm.
## Map The Work
Step one. Start with the work graph.
List the recurring work the startup ran in the last two weeks: customer-call notes, lead research, outbound drafts, support triage, product QA, onboarding, release notes, investor updates, weekly metrics, bug reproduction, recruiting screens, invoice review, competitor monitoring, all of it. If the work repeats, it is a candidate for encoding. Most founder calendars contain 20 to 40 such items; an early-stage team that lists them honestly will find ten to fifteen they did not realize were already routine.
Classify every work unit by autonomy level:
L1 is human only: a strategic call, a final hire, a major refund, a legal signature, a board communication.
L2 is AI prepared, human approved: an investor update draft, a contract redline, a pricing-page rewrite, a support macro.
L3 is AI executes, human supervises: inbound triage, meeting-note routing, lead enrichment, test generation.
L4 is autonomous inside clear limits: competitor monitoring, nightly report generation, invoice extraction from known vendors, simple anomaly detection.
The boring workflow usually wins. A weekly strategy memo feels like the prestigious thing to automate. Daily support-tagging — which is unglamorous and repetitive — recovers more hours and gives you cleaner ground truth, because it runs ten times as often. Frequency beats prestige. The first workflow to attack is frequent, measurable, reversible, and tied to a real bottleneck.
Do not automate work that is rare, unclear, high-trust, or unstable. A C.H. Robinson team tried to push email triage at 10,000 messages per day to L4 and reverted to L2 once supervision proved infeasible; the volume hid the cost of every misroute. If the team cannot explain what good output looks like, the workflow is not ready for encoding. If one wrong output can damage a customer relationship, move slowly. If the process changes every week, wait for it to stabilize or keep it as AI-assisted human work.
When you're done with this primary step, you have one page and three workflows to start: one personal (inbox triage, daily brief, investor-update draft), one customer-facing (call synthesis, ticket classification, lead enrichment), one internal (test generation, invoice extraction, the weekly metric narrative). Having too many experiments at the same time dilutes attention and produces twenty half-finished pilots, which is the most common failure mode at this stage.
## Build The Context System
Context is the AI native startup's operating memory. It's everything the company knows about itself, held where agents can read it. While models are interchangeable and improving every month, context is the part that's actually yours. It’s what separates an agent that works like a cofounder from one that works like a confused temp.
If the team spends more time rewriting agent output than reviewing it, the problem is rarely the prompt or the model. The agent just doesn’t know enough about the company — your customers, your product, your priorities, the decisions you already made and why.
There’s an easy diagnostic you can run weekly to ascertain the state of play: pick one representative task, hand it to a fresh agent with only the workspace context, and ask for three next actions. Two or more strong suggestions means the context layer is carrying weight. Three generic answers means the context is thin and the prompt cannot rescue it.
Start with one shared Git repository every team member and agent can read. Git wins for a simple reason: it's versioned, diffable, readable by humans and agents alike, and tied to no vendor's runtime. It will outlive every model and harness you run through it. The whole workspace at day seven can be one root with CLAUDE.md, context/company.md, context/product.md, context/customers.md, context/lessons.md, and GTD.md for active work.
A general rule of thumb is to keep it to 40–60 hand-written lines; a tight list of what to avoid beats 400 generated lines of slop. It won't solve every context problem, but it solves enough that agents stop hallucinating basic facts about your own company.
As the startup grows, split the context system by permission boundaries. There are a couple of ways to do this. For example: a shared company repo plus private repos per function (sales, product, engineering, finance, support). Another: private repos per project or customer with a shared root for company-wide context.
At enterprise scale, a private Git server (self-hosted Gitea, GitHub Enterprise, GitLab) gives directory-level or repo-level permissions so agents and humans see only the context they are allowed to see. Block's internal harness Goose reads the same artifact stream the rest of the company sees, scoped by role; the moment scoping drifts, agents start mixing public-conviction language with private-deal context. That’s why boundaries are incredibly important.
Three kinds of data feed the system.
Connectors pull from outside — SaaS tools, APIs, MCP servers, email, calendar, CRM, support, analytics, GitHub, Linear, Stripe, the warehouse, the docs. Every connector needs an identity, scoped permissions, audit logs, and managed credentials, or the sprawl quietly becomes your biggest security hole. An IAM layer like Zitadel carries that identity discipline. How you load the tools matters too: Anthropic's MCP code-execution work shows a filesystem-of-server-folders pattern dropping context use from ~150,000 tokens to ~2,000 versus loading every tool definition upfront — a 98.7% cut in token spend (your accounting team will thank you).
Data the company generates — specs, customer summaries, decisions, lessons, project notes, operating rules. Markdown by default, and one rule that matters more than the rest: keep raw separate from distilled. A call transcript is raw. The decision made on that call, the objection the customer raised, the follow-up owner, the renewal risk — that's distilled, and that's what agents actually query. Keep the decision log append-only, one decision per line, so the reasoning travels with the conclusion. If you conflate raw and distilled, you’ll drown in transcripts while never building the layer that's useful.
Databases and streams, where the source of truth already lives — product data in Postgres, marketing in the warehouse, events in analytics. Don't copy it blindly into markdown. Leave the database as the source of truth, give agents a limited-read user, document the schema in an agent-facing file (data-models/postgres.md), and spell out exactly which queries and writes are allowed. Agents should not be able to delete production data by default. The Replit incident from mid-2025 — a coding agent wiped a production database mid-session — is the standing reminder that a prompt instruction is not a security boundary.
The advanced version is a structured context graph. Before agents query anything, raw artifacts get processed into entities and relationships: people, companies, objections, commitments, feature requests, renewal risks, follow-ups, dates, decisions, source links. Instead of storing transcripts, you extract what's in them and link every call with the same people or project into a chain. Now an agent can answer "what's the renewal risk on Vandelay Industries?" and cite the exact line where the customer said it.
Provenance holds the whole thing together. Every agent summary has to trace back to its source — the transcript, the ticket, the commit, the invoice, the database row. Without it, the company fills with plausible summaries nobody can verify, and the first time a confident answer turns out wrong, trust in the entire agent layer collapses. With it, agents become auditable: a teammate clicks through to the source and settles the disagreement in seconds.
## Choose The Simplest Automation That Works
Now that you’ve built the context, it may be tempting to let the machine run wild through every task in the org. Do not do this. Say it with me: Do not turn every workflow into an agent.
The best AI-native systems are a blend of scripts, AI-assisted humans, deterministic workflows, and agents, each doing the work it's actually suited for. Your job as a founder is to reach for the lightest tool that can run the work safely: the fewest moving parts that still clear the quality bar.
Use a script when the step is deterministic — exporting a report, transforming a CSV, running tests, checking links, validating JSON, formatting the weekly metric pack.
Use AI-assisted human work when the output needs judgment before it leaves the company — investor updates, founder emails, pricing copy, contract notes.
Use a workflow when the steps are known in advance — ingest the call, summarize, extract objections, write the CRM note, create the follow-up. Workflow engines (LangGraph, Temporal, Inngest, Prefect) handle the ordering, retries, and observability.
Use an agent when the path can't be pre-specified — investigate a production bug, research a market, work an unusual support case, untangle a messy customer account. Browserbase's bb agent is one Slack-facing generalist that loads a different skill file and scoped permissions for each task; that beats building a separate bot per task, because the bots all drift apart over a long enough timeline.
A harness is the essential, non-negotiable safety layer around the model. A workable first version is six stages:
1. Preflight — check context and permissions before the agent burns a token.
2. Plan — decompose the task and expose the proposed steps.
3. Approve — a human or judge-model gate that catches a bad plan before execution.
4. Execute — run the work.
5. Verify — check the output against tests, schema, rubric, or examples.
6. Log — write what happened to a run file so the next iteration has ground truth.
Guardrails belong in code and config, not in prompts. A prompt that says "do not delete production data" is not a security boundary. The non-negotiables are explicit: cost caps per run and per day, retry caps, a maximum tool-call depth, scoped credentials per agent identity, no production writes without an approval step, no auto-merge on code, and a fleet-wide kill switch. The recursive-spawning incidents through 2025 — agents calling child agents calling child agents — cost teams real money before the harness layer caught up. Caps belong at the runtime, before the model gets a chance to ignore the instruction.
## Encode Skills And Evals
Everything up to this point has been setup. Encoding recurring work as skills and grading them with evals is the engine. It’s what turns a company that does the work into one that compounds it a little better every week.
A skill is reusable instructions plus examples for a recurring task. Run it by hand twice, then encode the parts that repeat. Every skill needs a clear shape: scope, inputs, context to load, procedure, output format, examples, escalation rule, owner, and run log.
If the file doesn't say what it accepts, what it returns, when it asks for help, and who maintains it, it's a long prompt, not a skill.
Here’s a skill template founders can adapt:
> Skill: customer-call-synthesis
> Scope: sales calls after transcript is available
> Inputs: transcript, account record, product context, open opportunities
> Load: ICP, pricing, product roadmap, objection taxonomy
> Steps: extract facts → cluster objections → identify risks → write follow-ups
> Output: CRM note · customer brief · feature requests · next actions
> Examples: 3 prior calls with expected notes
> Escalate: legal or security issue, churn risk, enterprise pricing
> Owner: revenue lead
> Logs: runs/<date>/<account>.md
> Eval: 30 historical calls with expected extraction fields
Start with founder-native skills:
- Customer-call synthesis — extracts objections, feature requests, risks, commitments, and next actions from raw transcripts.
- Inbox triage — sorts investor, customer, hiring, and operational messages, and drafts replies for the first three.
- Investor update — drafts the narrative from metrics and decisions, then cites both.
- Pricing-page teardown — compares the live page against the latest customer-objection log.
- Weekly metrics narrative — explains what changed, what broke, and what to inspect.
- Test generation — turns a spec into tests and a draft PR.
The eval is what makes a skill compound. Once a skill has a usable eval, prompt-tuning becomes optional: a small reflection model proposes changes, the eval ranks them, the best one ships automatically. Without an eval, every iteration is a taste argument between the founder and whoever wrote the last version.
An eval has three layers, and they stack in order.
First, hand-labeled ground truth — a human marks what good output looks like on real examples.
Second, deterministic checks, which cost nothing and return an unambiguous verdict: schema validity, numbers matching the source, links resolving, citations existing, tests passing.
Third, an LLM judge, but only for what the deterministic checks can't reach — writing quality, sentiment, whether the output matches the brief. A small fast model is enough, and it has to be calibrated against the human-marked examples before you trust it on the rest.
Let’s take customer-call synthesis as a case study on how to achieve this. Take thirty past calls and have the revenue lead mark up each — the facts that matter, the objections, the risks, the follow-ups. Some of the checking is deterministic: did it get the names right? Do the dollar figures match the contract? Are the follow-up dates in the right week? What a machine can't check is whether the brief actually sounds like the call, so an LLM judge does that part.
About fifty runs in, you see where it breaks, and it's usually the same two things: it loses track of who's talking when three or more people are on the call, or it merges two different objections into one. Those are what you fix. The problems you imagined before running it usually aren't the ones that show up, and you rewrite the skill against these clusters until it works consistently.
While outbound lead classification works differently, the eval structure is similar. Three hundred old leads, the founder marks each a plain yes or no — fits the ICP or doesn't. The mechanical checks are basic: the company's real, the website loads, the headcount's filled in. An LLM judge against the ICP description handles the rest. With the eval in place, an open-source prompt-evolution loop (GEPA, DSPy) rewrites the classifier prompt against the labels overnight. The founder never reads the final prompt. The eval verdict is the only thing that matters.
Both cases follow the same shape: hand-labeled ground truth first, deterministic checks next, an LLM judge for what remains, and the loop runs against the eval until acceptance crosses the threshold.
Evals mature in five escalating stages:
1. Spot check one example by hand
2. Score a handful of cases against a written rubric.
3. Run that rubric against 20–300 historical cases.
4. Test on a held-out set the agent never saw
5. Track the business metric the skill was built to move.
Evals get a skill ready to ship. Staying good is a different question, and you answer it with six numbers tracked every week: acceptance rate, override rate, cost per run, cycle time, review time, and incident count.
Acceptance rate is the one to watch. Below roughly 70% — minor edits still count as accepted — the skill isn't ready to move up an autonomy level to run with less oversight than it has now. When acceptance is low, the instinct is to rewrite the prompt. That's almost never the fix. It's usually one of four moves: load more context at runtime, tighten the skill's scope, add more worked examples to the file, or write a clearer escalation rule for the cases the agent shouldn't have taken on.
## Make The Team AI-Native
The founder goes first.
The fastest way to move a team onto a new way of operating is to show them live, within the context of your company. Show the morning brief that pulled from calendar, inbox, and Slack overnight; the customer synthesis from yesterday's calls; the test PR an agent opened against the spec; the investor-update draft built from the last metric pack.
The goal is calibration: seeing firsthand what the agent layer can and can't do. Jack Dorsey reportedly spent hours every morning through 2025 working directly with these tools before Block reorganized around them. It led to huge efficiency restructuring, and the decisions behind it came from leadership that had used the agents themselves.
Installation begins on day one. Onboarding should end with a useful AI artefact. Every teammate walks out of their first session with output they can ship that day — a cleaned customer brief, a support macro, a test PR, a pricing-page critique. Training that doesn't produce real work gets forgotten by the next week. Ramp's Glass tool went from 20 daily users to around 700 in three months on exactly this rule: every onboarding session ended with the new person adding one skill or one artifact to the shared library.
This means the human role gets bigger, not smaller. People design the system, own the relationships, judge the output, and carry the accountability. The agents handle execution. The teammate who only runs narrow tasks is exposed under this model. The one who can turn judgment into instructions, examples, and evals is worth more than they were before.
Hiring changes too. The bar for opening a role is higher now. Some of what used to need a hire is now a skill, so save new roles for the work that genuinely needs a person. When you do hire, test for the new shape of the job: skip the trivia, hand candidates a project too big to finish by hand in the time given, and watch how they direct agents through it. You're hiring for judgment, taste, and the ability to recover when an agent goes sideways. These are the parts of the work that just got more valuable.
What that looks like in practice: an analyst gets a real report to produce in three hours, sources collected and evidence pulled and a polished brief at the end. An engineer gets a day to clone a real product surface or build an internal tool from a spec, tests included. A growth hire gets a market map and campaign plan across 50 to 100 companies — scraping, clustering, writing, prioritizing. None of it is finishable by hand in the time given. That's the point: you're watching how they work with agents under pressure.
## Run The Startup As A Feedback Loop
By this point, you’ve pressure tested your automation and your team. Now you go back to the beginning and start again. An AI-native startup improves its operating system every week.
The review should address:
- what agents did
- where humans overrode them
- which evals failed
- which context was missing
- which skills need narrowing
- which workflows to kill
- which to move up an autonomy level.
Run two loops at once. The inner loop makes existing work better — lower cost per run, shorter cycle time, fewer incidents, less review time per artifact. The outer loop hunts for what's next: new customer segments, product ideas, pricing changes, partnerships, competitor moves, regulatory shifts, churn risk. Background agents feed the outer loop with candidates around the clock; humans decide which ones to chase.
The software factory is the biggest piece of the inner loop. Humans write the specs and tests, agents implement against them. Deterministic checks run on their own, humans review before anything merges. Start where the acceptance criteria are clear and the blast radius is small: test generation, dependency upgrades, migrations, internal tools, integration scaffolds, QA scripts, security autofixes.
There are two hard rules: nothing auto-merges, and no agent writes to production. Even Cursor, running autonomous cloud agents at scale, kept a human review gate on merges through early 2026. The gate is what let them scale the rest safely.
The market-learning system is the outer loop. Record the calls, extract objections, cluster feature requests, track competitors, watch usage shift, read the support patterns, study the deals you lost. Turn what you find into hypotheses, then test the strongest ones — customer conversations, landing-page tests, product experiments, fresh queries against the data. The agents propose. You choose. Hand an agent both the proposing and the deciding on strategy and it either settles into bland consensus or hill-climbs whatever metric is easiest to move.
Company-level self-improvement comes down to one skill: whether the team can write evals. Hand-label a few hundred examples good or bad, build the eval, wire it to a prompt-evolution loop. GEPA, DSPy, and frameworks like them do this directly — a small reflection model proposes prompt mutations, the eval ranks them on the labeled set, the winner ships, and it repeats. The founder writes the eval and reads the failure clusters. The founder never writes or reads the evolved prompt.
Agent capability is rarely the thing holding you back. If you can encode what good looks like — binary labels, a scoring rubric, a few business metrics — the loop runs at the scale of the whole company. If you can't, no amount of model capability closes the gap. Coding helps, but it isn't the bottleneck; a subject-matter expert who can reliably mark output good or bad can run the entire loop. The eval is the load-bearing artifact. The company stops compounding the moment the eval stops being written.
None of this needs a genius or a big team. It needs the discipline to map the work, build the context, write the evals, and run the loop every week. Discipline is the moat now. Everyone has the same models; the operating system is the secret sauce.
The Monastery exists to build that operating system with you: twelve weeks of pure focus, $2M, and operators already running the loop working alongside you to embed it into your company from day one.
Enter the Monastery, do the impossible with us.
## 相关链接
- [cyber•Fund](https://x.com/cyberfund)
- [@cyberfund](https://x.com/cyberfund)
- [25K](https://x.com/cyberfund/status/2058950286324986294/analytics)
- [@cyntro_py](https://x.com/@cyntro_py)
- [cyber.fund](https://cyber.fund/content/how-to-build-an-ai-native-startup)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:36 AM · May 26, 2026](https://x.com/cyberfund/status/2058950286324986294)
- [25.4K Views](https://x.com/cyberfund/status/2058950286324986294/analytics)
- [View quotes](https://x.com/cyberfund/status/2058950286324986294/quotes)
---
*导出时间: 2026/5/26 09:11:51*
---
## 中文翻译
# 如何构建 AI 原生初创公司
**作者**: cyber•Fund
**日期**: 2026-05-25T16:36:16.000Z
**来源**: [https://x.com/cyberfund/status/2058950286324986294](https://x.com/cyberfund/status/2058950286324986294)
---
一份面向从零到 AI 原生的创业者的实战指南：梳理工作、构建上下文、编写评估标准、运行循环。
文 / Stepan Gershuni, @cyntro_py
在 cyber.fund 博客阅读本文
上午9点，两家处于同一市场、同月成立的初创公司。在第一家，运营负责人还在处理旧的支持工单，分析师在重建上周的仪表盘，而创始人正在开会讨论一个没人能解决的客户来电。所有人都在手忙脚乱地修补昨天的问题，产品停滞不前。
在第二家公司，这一切都在昨晚完成了。代理对工单进行了分类，刷新了仪表盘，挖掘了隐藏在通话记录中的流失风险。创始人已经解决了问题，并正在与团队迭代产品。
是的，创始人在 AI 原生初创公司中的时间分配会不同，但这并不是根本性的变化。根本性的变化在于公司学习、迭代和进化的速度。第二家公司每一天的学习速度都会超过第一家。几周下来，这种优势将复合放大。几个月甚至几年后，只有一家会成功。
当公司的运营模式发生改变时，它就是 AI 原生的：更少的人进行更少的协调，代理执行更多重复性工作，而人类专注于方向、品味、关系、验证和问责。
对于寻求将公司构建或重塑为这一新现实的创始人来说，这看起来可能是一项艰巨的任务。但其实不必如此。构建 AI 原生始于几个步骤，一旦对这些步骤进行递归迭代，将彻底重组你公司的运营方式。
大概是这样的流程：
- 梳理工作
- 构建上下文系统
- 为每个环节选择最有效的简单自动化
- 将重复的工作转化为技能
- 编写评估标准以判断工作质量
- 以每周为节拍运行公司循环
## 梳理工作
第一步。从工作图谱开始。
列出初创公司过去两周内进行的重复性工作：客户通话记录、线索调研、外发邮件草稿、支持分类、产品 QA、入职培训、发布说明、投资者更新、周指标、Bug 复现、招聘筛选、发票审核、竞品监控等等。只要工作重复，它就是编码的候选对象。大多数创始人的日历包含 20 到 40 个此类项目；一个诚实的早期团队如果列出来，会发现 10 到 15 个他们没意识到已经是常规工作的项目。
按自主级别对每个工作单元进行分类：
L1 仅限人类：战略通话、最终录用、重大退款、法律签署、董事会沟通。
L2 AI 准备，人类批准：投资者更新草稿、合同修订、定价页面重写、支持宏。
L3 AI 执行，人类监督：进线分类、会议笔记路由、线索丰富化、测试生成。
L4 在明确限制内自主：竞品监控、夜间报告生成、来自已知供应商的发票提取、简单异常检测。
枯燥的工作流程通常胜出。每周的战略备忘录看起来像是值得自动化的高大上工作。而每日的支持标记——虽然不起眼且重复——却能节省更多时间，并给你提供更清晰的 Ground Truth（基本事实），因为它的运行频率是前者的十倍。频率胜过声望。第一个要攻克的工作流程应该是高频、可衡量、可逆转且与真正瓶颈挂钩的。
不要自动化那些罕见、模糊、高信任度或不稳定的工作。C.H. Robinson 的一个团队曾试图将每天 10,000 封邮件的分类推向 L4，但一旦证实监督不可行，又回退到了 L2；巨大的体量掩盖了每一次误判的成本。如果团队无法解释什么样的输出才算好，那么这个工作流程就还没准备好进行编码。如果一次错误输出就能损害客户关系，请慢下来。如果流程每周都在变，等它稳定下来，或者将其保留为 AI 辅助的人工工作。
当你完成这一首要步骤后，你就拥有一页纸和三个工作流程可以开始了：一个个人的（收件箱分类、每日简报、投资者更新草稿），一个面向客户的（通话合成、工单分类、线索丰富化），一个内部的（测试生成、发票提取、每周指标叙述）。同时进行太多实验会分散注意力，导致二十个半途而废的试点项目，这是此阶段最常见的失败模式。
## 构建上下文系统
上下文是 AI 原生初创公司的运营记忆。它是公司对自己所知的一切，保存在代理可以读取的地方。虽然模型可以互换且每月都在进步，但上下文才是真正属于你的部分。它是将一个像联合创始人一样工作的代理与一个像困惑的临时工一样工作的代理区分开来的关键。
如果团队重写代理输出的时间比审查的时间还多，那么问题很少出在提示词或模型上。代理只是对公司了解得不够多——你的客户、你的产品、你的优先级、你已经做出的决定以及原因。
有一个简单的诊断方法，你可以每周运行一次来确定现状：挑选一个具有代表性的任务，将其交给一个只有工作区上下文的全新代理，并要求它提供三个后续行动。如果有两个或更多强有力的建议，说明上下文层在起作用。如果是三个通用的回答，意味着上下文太单薄，提示词也无力回天。
从一个每个团队成员和代理都可以读取的共享 Git 仓库开始。Git 之所以胜出，原因很简单：它是版本化的、可对比的、人类和代理都可读的，且不依赖于任何供应商的运行时。它将比每一个通过它运行的模型和工具都更长久。第七天时的整个工作区可以是一个根目录，包含 CLAUDE.md、context/company.md、context/product.md、context/customers.md、context/lessons.md 以及用于当前工作的 GTD.md。
一个通用的经验法则是将其保持在 40-60 行手写内容；一份简练的“避坑”清单胜过 400 行生成的垃圾内容。这无法解决所有的上下文问题，但足以解决大部分问题，让代理不再对你公司的基本事实产生幻觉。
随着初创公司的成长，按权限边界拆分上下文系统。有几种方法可以做到这一点。例如：一个共享的公司仓库加上按职能（销售、产品、工程、财务、支持）划分的私有仓库。另一种：按项目或客户划分的私有仓库，加上用于全公司上下文的共享根目录。
在企业规模下，私有 Git 服务器（自托管的 Gitea、GitHub Enterprise、GitLab）提供目录级或仓库级的权限，以便代理和人类只能看到他们被允许看到的上下文。Block 的内部工具 Goose 读取与公司其他人相同的信息流，但按角色进行限定；一旦范围出现偏差，代理就会开始将面向公众的坚定措辞与私密的交易上下文混在一起。这就是为什么边界极其重要。
三类数据为系统提供支持。
连接器从外部拉取 —— SaaS 工具、API、MCP 服务器、电子邮件、日历、CRM、支持系统、分析系统、GitHub、Linear、Stripe、数据仓库、文档。每个连接器都需要身份、限定权限、审计日志和托管凭证，否则这种悄然蔓延将成为你最大的安全漏洞。像 Zitadel 这样的 IAM 层承载着这种身份规范。你加载工具的方式也很重要：Anthropic 的 MCP 代码执行工作展示了一种服务器文件夹文件系统模式，与预先加载每个工具定义相比，将上下文使用量从约 150,000 个 token 降至约 2,000 个 —— token 支出减少了 98.7%（你的财务团队会感谢你的）。
公司产生的数据 —— 规格说明书、客户摘要、决策、经验教训、项目笔记、运营规则。默认使用 Markdown，有一条规则比其他规则都重要：保持原始数据与精炼数据的分离。通话逐字稿是原始数据。基于该通话做出的决策、客户提出的异议、后续负责人、续约风险 —— 这是精炼数据，也是代理实际查询的内容。保持决策日志仅追加，每行一个决策，以便推理伴随着结论。如果你将原始数据和精炼数据混为一谈，你将淹没在逐字稿中，却永远无法构建出真正有用的层级。
数据库和流，事实的唯一来源已经存在于其中 —— Postgres 中的产品数据、仓库中的营销数据、分析系统中的事件。不要盲目地将其复制到 Markdown 中。将数据库保留为事实来源，给代理一个受限的读取用户，在面向代理的文件（data-models/postgres.md）中记录架构，并明确说明允许哪些查询和写入。默认情况下，代理不应能够删除生产数据。2025 年中期的 Replit 事件 —— 一个编码代理在会话期间擦除了生产数据库 —— 永远提醒着我们：提示指令不是安全边界。
高级版本是结构化的上下文图谱。在代理查询任何东西之前，原始工件会被处理成实体和关系：人员、公司、异议、承诺、功能请求、续约风险、后续跟进、日期、决策、来源链接。不再存储逐字稿，而是提取其中的内容，并将每个涉及相同人员或项目的通话链接成一条链。现在，代理可以回答“Vandelay Industries 的续约风险是什么？”，并引用客户说过的具体那一行。
出处将整个系统结合在一起。每个代理摘要都必须追溯回其来源 —— 逐字稿、工单、提交、发票、数据库行。没有它，公司就会充满看似合理但无人能验证的摘要，而第一次自信的回答被证明是错误时，对整个代理层的信任就会崩溃。有了它，代理就变得可审计：队友点击进入来源，并在几秒钟内解决分歧。
## 选择最有效的简单自动化
现在你已经构建了上下文，可能会忍不住让机器在组织中的每一项任务上肆意妄为。千万不要这样。跟我一起说：不要把每个工作流程都变成代理。
最好的 AI 原生系统是脚本、AI 辅助人工、确定性工作流程和代理的混合体，各自做它们真正擅长的工作。作为创始人，你的工作是用能安全运行工作的最轻量级工具：最少的移动部件，但仍能达到质量标准。
当步骤是确定性的时候，使用脚本 —— 导出报告、转换 CSV、运行测试、检查链接、验证 JSON、格式化每周指标包。
当输出在流出公司前需要判断时，使用 AI 辅助人工工作 —— 投资者更新、创始人电子邮件、定价文案、合同笔记。
当步骤预先已知时，使用工作流 —— 摄入通话、总结、提取异议、撰写 CRM 备注、创建后续跟进。工作流引擎（LangGraph、Temporal、Inngest、Prefect）处理排序、重试和可观测性。
当路径无法预先指定时，使用代理 —— 调查生产 Bug、研究市场、处理异常支持案例、理顺混乱的客户账户。Browserbase 的 bb 代理就是一个面向 Slack 的通用代理，它为每个任务加载不同的技能文件和限定权限；这比为每个任务构建单独的机器人要好，因为在足够长的时间线上，这些机器人都会出现偏差。
工具束是围绕模型的必不可少的、不可协商的安全层。一个可用的第一版包含六个阶段：
1. 预检 —— 在代理消耗 token 之前检查上下文和权限。
2. 计划 —— 分解任务并展示拟议的步骤。
3. 批准 —— 一个人类或法官模型的关卡，在执行前捕获糟糕的计划。
4. 执行 —— 运行工作。
5. 验证 —— 根据测试、架构、评分标准或示例检查输出。
6. 日志 —— 将发生的情况写入运行文件，以便下一次迭代有 Ground Truth 可依。
护栏应属于代码和配置，而不属于提示。提示词说“不要删除生产数据”并不是安全边界。不可协商的事项是明确的：每次运行和每天的费用上限、重试上限、最大工具调用深度、每个代理身份的限定凭证、没有审批步骤不得写入生产环境、代码不得自动合并，以及整个机群的终止开关。2025 年发生的递归生成事件 —— 代理调用子代理，子代理再调用子代理 —— 在工具束层赶上之前，让团队损失了真金白银。上限应设在运行时，在模型有机会忽略指令之前。
## 编码技能与评估
到目前为止，一切都是准备工作。将重复性工作编码为技能并用评估标准对其进行分级是引擎。正是这一点将一家“做工作”的公司转变为一家每周都做得更好一点的公司。
技能是针对重复任务的可复用指令加上示例。手动运行两次，然后编码重复的部分。每个技能都需要一个清晰的形态：范围、输入、要加载的上下文、流程、输出格式、示例、升级规则、所有者和运行日志。
如果文件没有说明它接受什么、返回什么、何时寻求帮助以及谁来维护它，那它就是一个长提示词，而不是技能。
以下是创始人可以改编的技能模板：
> 技能：customer-call-synthesis（客户通话合成）
> 范围：有逐字稿后的销售通话
> 输入：逐字稿、客户记录、产品上下文、开放机会
> 加载：ICP（理想客户画像）、定价、产品路线图、异议分类法
> 步骤：提取事实 → 聚类异议 → 识别风险 → 撰写后续行动
> 输出：CRM 备注 · 客户简报 · 功能请求 · 下一步行动
> 示例：3 个带有预期备注的历史通话
> 升级：法律或安全问题、流失风险、企业定价
> 所有者：营收负责人
> 日志：runs/<date>/<account>.md
> 评估：30 个带有预期提取字段的历史通话
从创始人原生技能开始：
- 客户通话合成 —— 从原始逐字稿中提取异议、功能请求、风险、承诺和后续行动。
- 收件箱分类 —— 对投资者、客户、招聘和运营消息进行分类，并为前三类起草回复。
- 投资者更新 —— 根据指标和决策起草叙述，然后引用这两者。
- 定价页面拆解 —— 将实时页面与最新的客户异议日志进行比较。
- 每周指标叙述 —— 解释变化了什么、出了什么问题以及需要检查什么。
- 测试生成 —— 将规格说明书转化为测试和草稿 PR。
评估是让技能产生复利效应的关键。一旦技能有了可用的评估，提示词调优就变得可有可无：一个小型的反思模型提出变更，评估对它们进行排名，最好的版本自动发布。没有评估，每一次迭代都是创始人与编写上一版本的人之间的口味之争。
评估有三个层级，它们按顺序叠加。
首先是人工标注的 Ground Truth —— 人类在真实示例上标记好的输出是什么样的。
其次是确定性检查，它们零成本并能返回明确的裁决：架构有效性、数字与来源匹配、链接可解析、引用存在、测试通过。
第三是 LLM 法官，仅用于确定性检查无法触及的领域 —— 写作质量、情感、输出是否符合简报。一个小而快的模型就足够了，并且在使用前必须根据人工标注的示例进行校准。
让我们以客户通话合成为例，看看如何实现这一点。拿出30个过去的通话，让营收负责人对每个进行标注 —— 重要的事实、异议、风险、后续行动。