JournalEnterprise

The moat of the agentic company

If your competitors can buy the same models, your advantage has to come from how you use them and what your company learns along the way.

Scott TaylorCo-founder & CEO · Memco8 min read

Some of the most advanced organisations we’re speaking to are thinking about a future in which their companies are 99% agents and 1% humans.

Treat the ratio as a thought experiment, not a staffing forecast. If another company can deploy comparable agents, what makes yours better?

With enough capable agents, a business could investigate more opportunities, produce more software and respond to more customers. Its competitors could do much the same. Producing more work would become a harder advantage to defend.

For a startup, a scaleup or an established enterprise, the opportunity is to make the organisation better through the work it does. Each deployment, customer interaction and difficult decision can contribute to an understanding of the business that another company cannot acquire by subscribing to the same model.

What your models do not know about your business

Knowledge of your business still has to be developed, however capable the model becomes.

A capable model can explain procurement, write software or analyse a contract. It does not arrive knowing why your last implementation stalled, which customer commitment changed the delivery plan, or which apparently sensible approach repeatedly failed in your operating environment.

Some of that information belongs in existing systems and documentation. Some emerges only when people reconcile what those systems say with what happened in practice. A project marked complete might have required weeks of unrecorded expert intervention. A rejected proposal might have exposed a constraint that matters to the next customer in the same market.

General knowledge can become commoditised without making every company equally good at applying it. You still have to establish what works in your environment, learn from the consequences and recognise when an approach has stopped working.

Model quality still matters. So do product, distribution, customer relationships and access to capital. Organisational learning can strengthen those advantages by making the company better at using what it already has.

Where the learning gets lost

A company can generate more output while continuing to make the same mistakes.

An agent completes a task, a person repairs the result and the workflow moves on. The output gets counted. The intervention may survive only in a conversation, while the reason it was necessary never becomes available to another agent.

Adding agents to that arrangement can increase demand for the same small group of experts. Those people become the route through which local knowledge reaches each new task. Their judgement is valuable; repeatedly asking them to explain an already established constraint is a poor use of it.

There is evidence that AI can help distribute expertise. In a published study of AI assistance for human customer-support workers, Erik Brynjolfsson, Danielle Li and Lindsey Raymond found that issues resolved per hour increased by 15% on average, with larger gains among less experienced workers and evidence of worker learning.[1]

As work moves between people, agents and tools, that transfer needs to become part of the workflow. A lesson needs enough context to be applied correctly, and later results must be able to overturn it.

That learning can come from successful work, failed attempts, expert corrections or changing conditions. Capturing only the final answer loses much of the evidence needed to understand why it worked.

What a learning advantage looks like

A useful lesson may only become clear when several pieces of evidence are brought together.

Consider a hypothetical software company onboarding enterprise customers. Its standing guidance says that large customers need an engineer involved early. Smaller customers usually go through a standard process.

Suppose the team brings together onboarding records, support incidents and engineer corrections. Several small-customer deployments succeeded only because an engineer quietly repaired an identity configuration. Some large deployments were straightforward because the relevant setup had already been tested. A later connector release removed one of the recurring problems.

The pattern seems to have more to do with identity configuration, connector version and whether that setup has been tested than with the size of the customer.

The team can test that explanation on subsequent deployments before changing the guidance. An onboarding agent can then check the relevant configuration before involving an engineer. Support agents can use the diagnostic findings within their own permissions. Where the evidence is weak, the system can preserve the uncertainty and require review.

Over time, further outcomes might strengthen the guidance, reveal an exception or make it obsolete. The company is developing a better understanding of when expert attention is needed and when the standard process is sufficient.

Customers could face fewer avoidable delays, while engineers spend less time on low-risk work. The company retains why it reached that judgement, along with the evidence needed to revise it.

When useful knowledge becomes a moat

Knowledge becomes a moat when it helps the company do valuable work better in ways a competitor cannot readily reproduce.

Many lessons will not meet that test. A generic prompt, a widely documented integration fix or a simple process improvement may be useful without creating much competitive protection. Some hard-won workarounds will become irrelevant after a model or software upgrade. A large private archive is no guarantee of an advantage.

The stronger case has four characteristics:

  • The experience is difficult to recreate. It comes from customer relationships, operating conditions, experiments and decisions that a competitor cannot simply download.
  • The knowledge changes consequential work. It improves delivery reliability, decision quality, customer outcomes or the effort required to achieve an acceptable result.
  • Later work tests and improves earlier conclusions. The organisation can distinguish a reusable approach from a coincidence, a hidden human rescue or a rule that no longer applies.
  • The value survives changes in execution tools. New agents and models can use relevant knowledge without the company rebuilding its understanding from scratch.

These conditions explain why two companies could buy the same knowledge infrastructure and develop very different advantages. Their experience differs, as does their ability to interpret it and act on what they learn.

There can also be a reinforcing effect. Better delivery may earn access to more demanding customer work, which creates opportunities to learn things that a less capable competitor has not encountered. That only compounds if the organisation can turn those experiences into improvements it actually uses.

The advantage can weaken too. Markets change, old practices become constraints, and a competitor with less history may learn faster. The defensible asset needs continual maintenance; its age alone does not make it valuable.

Keeping shared knowledge trustworthy

People and agents need to know where a lesson came from and whether it still applies.

A lesson about one customer may contain information another team is not entitled to see. A conclusion inferred from several incidents may still be uncertain. An approach that worked under an old contract may be prohibited under the current one. Even a generalised lesson can reveal sensitive facts about the work from which it was derived.

Permissions and limits have to stay attached to a lesson when it is reused. Agents need to know where a lesson applies, what supports it and whether they are authorised to use it. The organisation needs a way to correct, restrict or retire guidance without hunting through every prompt into which it has been copied.

Reviewing every routine agent action manually would consume the capacity automation was meant to create. People still need to set standards, decide which actions require approval and investigate the evidence behind consequential conclusions.

When changing models or tools, the organisation needs to retain more than a collection of statements. The sources, permissions and conditions attached to them matter too. Keeping that knowledge does not remove the need to test how a new model applies it.

Start with one recurring workflow

Look for work where a previous experience could help someone make a better decision next time.

For a startup, this might be a narrow part of customer delivery where founders repeatedly supply judgement that has not yet become part of the process. The opportunity is to make a small amount of hard-won understanding usable without building a large administrative burden.

As a company scales, the problem changes. Different teams encounter related situations but develop their understanding separately. Shared knowledge can help them benefit from one another’s work while preserving the differences that genuinely matter between customers, products or markets.

An enterprise may have a much deeper operating history. Its challenge is to establish which parts remain current, who is entitled to use them and where they can improve a live workflow. Decades of records are an advantage only to the extent that the organisation can extract reliable, relevant knowledge from them.

Choose one of those workflows and run a test with a clear definition of success:

  1. Choose work with recurring decisions and observable results. Onboarding, support resolution or a defined engineering workflow can provide a useful starting point. Establish what an acceptable result means before measuring speed.
  2. Record the evidence needed to understand the outcome. Include the relevant attempts, interventions and conditions within legitimate access and retention boundaries. A task marked successful should not conceal the human effort required to make it so.
  3. Test candidate lessons on later work. Compare them with a credible alternative: the same model and tools, maintained documentation and well-written shared instructions. Keep evaluation cases separate from the experience used to develop the lessons.
  4. Measure the complete cost of an accepted result. Include model usage, rework, expert review and the effort of maintaining the knowledge. Released senior capacity is useful, but it is not automatically a cash saving.
  5. Revisit the guidance when conditions change. A new model, product release, policy or contradictory outcome should prompt reassessment. Some knowledge should be retired.

A growing knowledge store and frequent retrievals tell you little unless earlier experience is improving the quality or cost of later work.

Building for the agentic company

A company’s accumulated learning should remain under its control as its agents and tools change.

At memco, we’re working on how evidence from agent work becomes shared, governed knowledge. That includes combining lessons from different tasks, refining them as new evidence arrives and making them available to the agents entitled to use them. The organisation needs to remain able to inspect and change what its agents learn.

This matters well before a company approaches the 99% agents scenario. It starts whenever more work is being delegated than a small group of experts can personally supervise and explain.

Before your next rollout, pick an important workflow and ask what a new agent would inherit from the last year of work. Give it access to that knowledge, within the right boundaries, and test whether it improves the result. If later work gets better, you have something worth investing in and a practical way to judge whether it keeps improving.

Sources

[1] https://academic.oup.com/qje/article/140/2/889/7990658 — Generative AI at Work (Quarterly Journal of Economics, 2025)

Keep reading

All essays

Running coding agents on real repos?

Quick start