What Makes a Company AI-Native? Start With What Its Agents Can Read

In the Bilibili talk on AI-native organizations, Zara Zhang told a room of managers that when their AI agent does a bad job, the agent is probably fine. "大概率不是它的问题，是你的问题," she said: most likely the problem is yours. Her argument was that today's models are capable enough for most office work, and that they fail because nobody gave them the context a new colleague would get in their first month.

Her examples suggest a practical definition of AI-native that goes beyond choosing a model. An AI-native company is one whose meetings, decisions, data and processes can be read and acted on by agents, with clear limits on what those agents may do and a named person responsible for the result.

Meetings Capture Context That Documents Miss

Ask where a company's real decisions live and the honest answer is meetings, chat threads and hallway conversations. The documents come later, if they come at all. Zhang treats meeting records as a way to supply context that formal documents often miss. In her own setup, the agent fetches every meeting's notes when it ends and returns three lists: a summary, her to-dos, and the to-dos it can do itself. She replies with the numbers of the ones it should start. Her July talk write-up describes a similar handoff from meeting notes to reviewed actions.

Zhang cites Shopify as an example: its internal agent works only in group channels and has no private chat, which means everyone sees how colleagues use it and learns from that. A calendar entry for a client visit is enough for an agent with the right access to pull the client's history from the CRM and prepare a brief, without anyone writing a prompt.

Privacy belongs in this design from the first day. Recording everything means storing personal information, and the retention, redaction and deletion rules we described in an earlier piece on agent security and privacy are what make that recording defensible.

Use the Cheapest Layer That Can Do the Job

The opposite mistake is making everything an agent. The open ForceInjection guide to AI-native engineering puts the rule bluntly: if a tool can do it, do not use an agent. It ranks the layers by cost, from fixed tools (ordinary code, exposed to AI through a protocol such as MCP), to skills (written procedures an AI follows), to agents (systems that decide the next step in situations nobody scripted).

Three questions sort each task. Can conventional software do it in a way you can verify? Then it is a tool. Is it a fixed sequence of steps? Then it is a skill. Does it need to decide what to do next in a new situation? Only then is it an agent. The guide's worked example is a power-trading system for a network of charging stations, with five roles in the decision chain, and only one of the five turns out to need an agent. Forecasting can use statistical or machine-learning models, while risk limits and order submission need explicit, testable rules. The example is an architectural argument, not independent evidence of deployment results.

Apply that test before assigning a step to an agent. If a fixed rule covers it, ordinary code will usually be easier to test. Reserve model judgment for the uncertain parts and measure its error rate and cost there.

Every Decision Still Has an Owner

The same guide states that final decisions, risk and responsibility for going live stay with a clearly named human owner. That responsibility needs to be visible in each workflow. Agents draft, collect, check and act within limits; people sign. We wrote about how to fit that into existing approval chains in Let AI Draft, Let People Sign, and the principle has only become more important as agents take on longer tasks.

Cost needs an owner too. Assign a budget to each workflow, measure cost per completed task and set a stop condition before unattended runs begin. A cheap model that retries endlessly can cost more than a larger model that finishes the job. Budget controls should cover tool calls and infrastructure as well as tokens.

Expect the Dip, and Plan for It

Zhang closes with the productivity J-curve: learning and redesign can consume time before benefits appear. That is a reason to budget for experimentation. Continued spending without measurable improvement still calls for changing or stopping the experiment.

Record why each trial fails. Missing access, an unwritten decision or late data may explain the problem; the model may also be unable to perform the task reliably. Those causes call for different responses.

A Test You Can Run on Monday

Pick one recurring meeting whose participants have agreed to recording and the intended AI use. Give an agent a redacted transcript and the minimum read access needed, then ask it to propose actions. Review those actions before execution. Sort unfinished tasks by missing access, context, ownership or reliable data, and prioritise the gaps by business impact and frequency.