Agentic Coding Is Draining Your Moat 

A practical way to refill it: inventions.md and fast (detailed!) provisional filings 

In brief: 

• Agentic coding collapses the time and capital advantages that used to protect early-stage software companies. When competitors can reach feature parity in days, “shipping faster” stops being a moat and becomes table stakes. 

• One of the few levers you can pull early is intellectual property, but only if you capture inventions while you build. 

• The simplest workflow I’ve found: instruct your coding agent to surface patentable technical ideas and log them in an inventions.md file, then file provisional patent applications quickly on the ideas that survive a rough patentability screen. 

A large part of the moat you thought you had was “build friction” 

For most of the modern software era, defensibility was quietly created by friction and resource scarcity. It took time to design and implement features. It took money to hire a team. It took deep software expertise to integrate and ship reliably. Those constraints acted like natural moats. Not unbeatable ones, but real enough that “first mover plus solid execution” often bought you a runway. 

Agentic coding is stripping that friction away. 

When the cost of getting to “working product that’s good enough” collapses, your feature set becomes easier to replicate, your differentiation window compresses, and the old bargain (build something hard enough and the market will reward the effort) starts breaking down. 

Here is the changing reality: if a capable team, or even a motivated individual, can recreate your product’s core experience in days, your “feature moat” is not a moat anymore. It is a backlog. 

Five hours that changed how I think about defensibility 

This recently became very real for me. 

There is an exercise app I have used for years and genuinely admire. I wanted similar interaction patterns for a completely different vertical and use case, with capabilities the original does not offer. So, I sat down with an agentic coding tool and built it. Not to compete with the original. Not to commercialize. Just to solve my own problem in my own domain. 

It took about five hours to get a credible, usable version running. 

And yes, I appreciate the irony of a patent attorney telling this story. That is exactly the point. If it is this easy for one person to take an interaction model they like and adapt it for a new context in an afternoon, imagine what a well-resourced team can do with your product as their reference point. 

The barrier between “idea” and “working alternative” is getting radically thinner. Today it is five hours for a personal project. Tomorrow it is five hours for something that looks uncomfortably close to your early-stage product. 

If you are building a new app, the real question is not “how fast can we ship?” It is: what can we ship that is actually defensible once shipping gets cheap? 

The modern moat stack is shifting upward 

This does not mean moats are gone. It means the reliable moats are moving away from implementation and toward things that are harder to replicate quickly. 

Distribution and trust, especially in enterprise. Workflow embedding and deep integrations into real operations. Proprietary data and feedback loops, when they are truly unique and compounding. Compliance credibility, when it creates real procurement friction. Contracts, channel partnerships, social networks, and “app memory” that multiply switching costs. 

Those are all real. They are just not universal, and they are rarely available on day one. 

Early-stage teams often do not have deep distribution. They do not have an entrenched workflow position or network of users. Their data advantage is still nascent. Their compliance story is still on the roadmap. Which leaves a gap. 

And that gap is where IP, done correctly and early, can matter. 

When code is cheap, exclusion rights get relatively more valuable 

Not every software product is patentable, and not every patent is worth enforcing. At the same time, a thoughtful IP strategy becomes more valuable when replication gets cheap, because it can create enforceable speed bumps where speed alone no longer differentiates. 

The trick is that most teams miss the real bottleneck. 

It is not “we should file patents.” It is: we do not reliably notice, capture, and articulate inventions while we build. 

Agentic coding makes this worse. When you are shipping quickly with an agent, you are moving fast, generating lots of implementations, and you can easily fail to recognize the few ideas that are actually invention-grade. So the question becomes operational: how do you capture patentable technical ideas as a byproduct of agentic development, without turning your engineering process into a legal process? 

The workflow: inventions.md as your invention capture layer 

If you are already using agentic coding, you probably have some version of these files: 

• .agent, agent.md, claude.md, or codex.md for instructions and preferences that tell the agent how to work 

• lessons-learned.md as a running log of what worked, what did not, and how to avoid repeating mistakes 

The missing file, the one that changes your defensibility posture, is: 

inventions.md 

A simple markdown file where your agent deposits candidate inventions that arise during development, along with a rough-cut analysis of patentability. 

This is not about “patent everything.” It is about not losing the few ideas that matter in the blur of rapid iteration. 

What goes into inventions.md 

Only entries that plausibly meet three filters: 

Novelty. Is this meaningfully different from what the agent (and the team) already knows exists? The agent has a broad knowledge base. Use it to propose search keywords and identify the closest known approaches. But treat any novelty assessment as unconfirmed until counsel does a quick prior art screen. The agent is useful for a first cut, not a final answer. 

Non-obviousness. Is it more than a straightforward combination of common techniques? If you are just plugging together standard libraries in a standard way, that is probably not going to clear the bar. 

Eligibility and technical character. This is the one that trips people (and patent applications) up. The solution needs to be a technical solution to a technical problem, not just a business rule, a pricing scheme, or generic automation. If your “invention” is basically “take an existing business workflow and do it with AI,” you are at higher risk under Section 101 unless you can articulate a specific technical improvement: better performance, tighter security, improved reliability, lower latency, or similar. But if you have come up with a specific mechanism that delivers that kind of concrete technical benefit, you are in much better territory. 

The key move: instruct the agent to watch for inventions while building 

This is the part most people skip. They say “we should do patents later,” and then later they have no contemporaneous invention record, fuzzy recollections, a product that already shipped (and possibly already publicly disclosed), and a scramble to reverse-engineer invention narratives from the repo history. 

Instead, bake one instruction into your agent’s operating file. 

Think of it as a separation of concerns. Your agent.md (or claude.md or codex.md) holds the policy: when to look for inventions, what criteria to apply, how to format a candidate. Your inventions.md is the structured log: easy to review, easy to triage. This keeps inventions.md clean and prevents the criteria from drifting over time. 

In practice, most projects will not generate many entries. That is fine. Selectivity is a feature, not a bug. 

In one app I built through agentic coding, nothing made the cut. No inventions worth logging. But that outcome was actually useful: it told me the build was mostly composition and execution, not invention. Knowing that early is valuable too. 

How to set it up: two approaches 

There are two practical ways to run this, and the right one depends on what you are building and how sensitive the work is. 

Approach 1: Proposal-first (best for most teams). The agent does not write to inventions.md on its own. When it spots something that looks like it might qualify, it summarizes the candidate in the chat and asks whether you want to log it. You review, and if it passes your gut check, you tell the agent to append it. This gives you control over what becomes a written record, which matters if you are ever working near client-sensitive territory or if you are still calibrating the agent’s judgment. I would start here. 

Approach 2: Auto-log with a throttle (best for rapid internal prototyping). The agent appends directly to inventions.md whenever it hits medium or high confidence on the patentability filters, subject to a cap per day. This maximizes capture during fast-moving internal builds where you trust the rubric and do not want to break flow. During weekly review, move any entries that do not hold up to the “Rejected” section with a one-line reason rather than deleting them. That preserves an audit trail. 

For either approach, add this block to your agent.md: 

## Invention Capture 
 
While building, watch for technical mechanisms that solve a technical 
constraint: performance, reliability, security/privacy, data integrity, 
orchestration, monitoring/guardrails, evaluation. 
 
Do NOT treat “new workflow” or “business logic” as an invention unless 
there is a concrete technical mechanism beyond generic automation. 
 
When you think you found one: 
– Summarize it in 2-4 sentences in chat under “Candidate invention.” 
– Ask: “Log this to inventions.md?” 
– Only if approved, append an entry using the template below. 

And structure each inventions.md entry like this: 

## [Short descriptive name] 
**Date:** YYYY-MM-DD 
**Technical problem:** What constraint or limitation prompted this? 
**Mechanism:** How does it work? (steps, architecture, data flow) 
**Why it might be novel:** How does this differ from common approaches? 
**Why it might be non-obvious:** Why wouldn’t a skilled developer 
    reach for this solution automatically? 
**Technical character:** What technical improvement does it produce? 
    (not just a business outcome) 
**What a competitor must copy:** What specifically would a fast 
    follower need to replicate? 
**Evidence / measurement:** Any concrete data? (latency reduced by X, 
    memory saved, fewer failures, benchmark results, etc.) 
**Implementation anchor:** Repo path, commit hash, or key pseudocode 
    so counsel can find the technical detail later. 
**Human conception narrative:** What specific decisions did a human 
    make? (Architecture choices, constraints defined, parameter 
    selections, control logic, evaluation criteria, etc.) 
**Proposed inventor(s):** Which human(s) contributed to conception 
    of the claimed mechanism? 
**Disclosure risk:** Public demo planned? Already shipped behind a 
    feature flag? Customer NDA only? Note any date constraints. 
**Confidence:** Low / Medium / High (and a brief reason why) 
**Next step:** Ignore / Discuss further / Draft provisional 

Keep a short triage section at the top of inventions.md as a running scoreboard: 

## IP Triage 
– **To discuss:** [list] 
– **Rejected (with reason):** [list] 
– **Provisionals filed or planned:** [list] 

That turns the file into something you actually act on instead of a log that nobody revisits. 

A question you should be asking: if the agent suggested it, who is the inventor? 

If you are using AI agents to help build software and those agents are surfacing candidate inventions, there is a threshold question that matters before anything else: who gets named as the inventor? 

The answer, under current US law and across major patent systems globally, is clear. Only a natural person can be an inventor. An AI system cannot. The Federal Circuit confirmed this in Thaler v. Vidal, holding that the Patent Act requires a human inventor. The USPTO’s Revised Inventorship Guidance for AI-Assisted Inventions, published Nov. 26, 2025 (USPTO) and Nov. 28, 2025 (Federal Register), reinforces the point explicitly: AI systems are tools, analogous to lab equipment or software. Inventorship turns on human “conception,” which the guidance defines in the traditional way as a definite and permanent idea of the complete invention formed in the mind of a natural person. Major patent systems, including the US, EPO, UK, and Australia, have all rejected AI systems as inventors; inventorship still turns on human conception. 

The practical consequences are important. If no human can credibly claim conception of the mechanism you want to patent, you may not have a validly patentable invention, because there is no lawful inventor to name. 

But for most teams building with agentic coding tools, this is less of a barrier than it sounds. 

Agentic coding is collaborative. The human defines the problem. The human sets constraints and architectural direction. The human evaluates alternatives the agent proposes, rejects some, and pursues others. The human decides what “good” looks like. The agent generates options and writes code, but conception (the part the law cares about) is usually happening in the human’s head. 

The challenge is not whether human conception exists. The challenge is documenting it clearly enough, and early enough, that you can demonstrate it later. 

This is another reason the inventions.md workflow matters. Each logged entry should capture not just the technical mechanism and patentability rationale, but also a brief record of the human decisions that shaped the invention. Which human defined the core constraint? Who chose the architectural approach over alternatives? Who set the evaluation criteria? That record, created at the moment of invention rather than reconstructed months later, is exactly what patent counsel needs to support an inventorship determination. 

In practice, I recommend adding two fields (see the template above) to every inventions.md entry: 

Human conception narrative: What specific decisions did a human make? Architecture choices, constraints defined, parameter selections, control logic, evaluation criteria. 

Proposed inventor(s): Which human or humans contributed to conception of the claimed mechanism? 

And in your agent.md instructions, add a simple rule: when the agent proposes an inventions.md entry, it should also ask “Who is the human inventor, and what specific decisions did they make that shaped this mechanism?” If the human contribution is unclear, the agent should flag the entry as an inventorship risk so the team can resolve it before filing. 

This is not busywork. It is the connective tissue between your development process and a defensible patent filing. And it takes about thirty seconds per entry to fill in. 

One more note on this. If the agent genuinely proposed something entirely on its own, with no meaningful human direction shaping the core mechanism, that is worth acknowledging honestly. It does not mean the idea is worthless. It means that particular innovation might be better protected through trade secret, speed to market, or other means rather than a patent. Knowing that distinction early saves time and money. 

The second half: move fast from inventions.md to a provisional 

Capturing ideas is step one. The moat-refilling move is step two: file provisional patent applications quickly, and frequently when warranted. 

If agentic coding compresses your timeline, it also compresses your competitor’s timeline. You should assume other teams are moving just as fast as you are. That creates a straightforward strategy shift: 

Do not wait for perfection. Do not wait until the product is “done.” Do not wait until you have ten inventions. 

When a real invention shows up, you want priority. The US patent system is a first-inventor-to-file system in practice, meaning priority goes to the early filer. And the practical, founder-friendly tool for establishing priority is the provisional patent application. It gives you a filing date (which matters enormously), costs relatively little, and buys you twelve months to decide whether to pursue a full application. 

An important clarification: “fast” means fast to file a real technical disclosure, not fast to file a napkin sketch. A thin provisional can be worse than none because it creates false confidence and weak priority. The inventions.md entry, especially the “mechanism” and “implementation anchor” fields, gives you a head start on the level of technical detail a provisional actually needs. But the filing itself should contain enough specificity to support the claims you might eventually pursue. If the description would not enable a skilled developer to build the invention, it is not ready. 

One more timing consideration that reinforces the “file early” message: if you might want patent rights outside the United States, file before you ship, blog, demo, or present publicly. Many jurisdictions operate under absolute novelty rules, meaning any public disclosure before filing can permanently destroy your ability to get a patent there. The US offers a one-year grace period for your own disclosures, but most of the rest of the world does not. 

The operational discipline looks like this: an inventions.md entry appears with a rough patentability rationale. The founder, technical lead, and counsel do a quick review, even if it is informal. If the idea survives, you file a provisional with enough technical detail to support the claims you might eventually pursue. Then you keep building, keep logging, and upgrade selectively to non-provisional (utility) applications later. 

This is how you avoid the classic trap: you shipped fast and then realized too late that the only defensible part was never documented properly. 

A founder-grade playbook for building today 

If you are shipping with agents right now, here is a pragmatic sequence that does not kill velocity: 

Admit the default. Your feature moat is shrinking. If your defensibility story is “we are faster,” assume that advantage decays. 

Identify the “must-copy mechanisms,” not the features. Ask yourself: what would a fast follower have to replicate under the hood to match your outcomes? That is where the real invention tends to live. 

Split mechanisms into patentable versus secret-keepable. If it can be reverse-engineered from the product, it is not a durable trade secret. If it cannot be observed from the outside, consider whether trade secret protection might be the better path. 

Implement inventions.md and one weekly invention review. A 20 to 30 minute weekly ritual beats a quarterly scramble every time. 

Document human conception as you go. When the agent surfaces something interesting, take thirty seconds to record what you decided and why. That record is the foundation of a defensible patent filing. 

File provisionals on the few ideas that matter. Early priority can be worth more than late perfection. But make sure each provisional is enablement-grade, not a placeholder. 

Watch your disclosure clock. If you plan to demo, ship, or blog about a feature that contains a patentable mechanism, file the provisional first. Especially if you want international rights. 

Treat IP as leverage, not a trophy. Even when you never enforce a patent, the portfolio can matter for fundraising diligence, partnership leverage, competitive deterrence, M&A value, and negotiating power when platforms shift under you. 

The core point 

AI is not just changing how we build software. It is changing what is defensible. 

As agentic coding lowers the cost of replication, implementation becomes cheaper and faster to copy. Workflow and trust moats still exist, but they take time, and many startups will not have them in the early innings. 

That is why this matters now. In a world where code is cheap, IP is one of the few tools that can convert true invention into lasting advantage. But only if you capture invention as you build it, and only if you can demonstrate that a human being conceived it. 

Start with a file. inventions.md. Then move fast. File the provisional. 

Quick-start: the Friday IP ritual 

For engineers who want a process primitive they can start this week: 

FRIDAY 2:30 PM — IP TRIAGE (20 min) 
 
1. Open inventions.md 
2. Review any new entries from the week 
   – Does the mechanism still look novel with fresh eyes? 
   – Is the human conception narrative filled in? 
   – Is there a disclosure risk date approaching? 
3. Move weak entries to “Rejected (with reason)” 
4. For surviving entries: flag 0-1 for provisional drafting 
5. Update the IP Triage scoreboard at the top of the file 
6. Done. Ship the rest of the afternoon. 

That is the entire overhead. Twenty minutes a week, and you never lose an invention to the blur of fast iteration again. 

Andre is a patent attorney who works with Bay Area technology companies, from early-stage startups to major corporations, on patent strategy and prosecution. He also builds software with agentic coding tools, which is how he started yelling at founders about moats.