Mindling

On 25 April 2026 an AI coding agent hit a credential mismatch in a staging environment. Instead of stopping to ask, it found an over-permissioned API token sitting in an unrelated file and deleted a production database. The backups lived in the same volume, so they went too. The whole thing took nine seconds. The most recent recoverable backup was three months old.

The post-mortems agree on the cause, and it is not that the model was bad. The boundary was advisory — a system prompt asking the agent to behave, rather than a gate that could refuse. Destructive operations needed no confirmation, a staging credential reached production, and there was no out-of-band approval step.

That is the category of failure Mindling is built for. Not smarter agents — enforceable boundaries at the point of action.

To be precise about the limits of that claim: Mindling governs the workflow around agents on a developer’s own machine. It would not have scoped another company’s infrastructure tokens, and it is not being offered as a fix for that incident. What the incident shows is the pattern — and Mindling’s answer to the pattern is that the safe behaviour is enforced in the code path instead of written in a document.

Read the full write-up: “The boundary was advisory” →

On 11 May 2026 the Mindling directory was empty. Ninety-eight days later it held 250 product modules and roughly 68,800 lines of Python, 139 test files carrying 2,156 tests, 311 route handlers and 34 published capability surfaces, across 1,413 commits by one author.

I did not type most of it. I directed AI coding agents and reviewed, tested and governed their work — which is exactly the activity Mindling exists to make safe.

It Ran Its Own Construction, And The Gates Held

Mindling was not built and then demonstrated. It has been the system of record for its own development since roughly week two:

• 353 development tickets — 262 with acceptance criteria, 131 with test evidence;
• 257 commits and 111 pushes executed through its own governed source-control path;
• 4 automated actions blocked and 1 push refused — against me, on my own repository;
• 165 technology decisions recorded by its research engine across 149 reports;
• 105 durable learning assets, linked by 1,859 evidence edges.

A governance layer that has never refused anything is decoration. This one stopped its own author.

Stated Plainly

Version 0.1.0. Of the 34 published surfaces, 7 are beta and 27 are advisory. None is production-grade yet — and that label is enforced by tests, which is why the number can be trusted. This is early software, and it says so in its own interface.

What Mindling Is

Mindling is a local-first operating layer for AI-assisted software work. It helps a builder turn AI speed into scoped, reviewed, evidenced, and approved work instead of scattered chats, half-finished tasks, and uncertain closeout.

Mindling does not replace coding agents. It governs the work around them:

• what is being built;
• what context the agent receives;
• what evidence must come back;
• which review gate applies;
• what gets documented;
• when the human owner can safely approve the result.

Why Now

AI coding tools are already changing how software gets built. The next problem is not whether AI can produce code. The problem is whether a builder can trust, review, document, and close the work without losing context or control.

What Exists Now

• local app surface;
• issue intake and lifecycle behavior;
• local-first project state with optional external sync;
• agent and department routing model;
• QA and review gates;
• evidence-oriented workflow;
• 34 published capability surfaces, version 0.1.0 (7 beta, 27 advisory, none production-grade yet);
• 2,156 automated tests across 139 files;
• internal company model with 15 department manifests and 16 explicit governed agent profiles.

The 353 figure is a count of real development tickets in the operating database — 262 carrying acceptance criteria and 131 carrying test evidence. It is measured, not estimated.

The Ask

The immediate ask is development sponsorship, not a securities offering. Recommended initial support window: 90 days.

• Essential: $100/month
• Builder: $250/month
• Strategic: $500/month

What Supporters Get

Private progress updates, early access when usable, demo walkthroughs, visibility into what funding unlocked, roadmap influence, and first updates about future beta, paid product, advisor, or formal funding paths if those become appropriate.

Supporters do not receive equity, repayment, profit participation, revenue share, or guaranteed financial return through this sponsorship packet.

Development sponsorship means someone supports the build because they want Mindling to exist, want an inside view, or want early access to the product as it becomes usable. It does not create ownership, repayment rights, investment rights, profit participation, or revenue share.

Sponsor Levels

What Sponsors Receive

• Inside view of the build.
• Monthly progress report.
• Demo walkthrough at meaningful milestones.
• Early access when usable.
• Ability to submit workflow pain for consideration.
• Optional acknowledgement as an early development supporter.
• Early updates about future beta, paid product, advisor, or formal funding paths if those become appropriate.

What Sponsors Do Not Receive

• No equity.
• No repayment promise.
• No guaranteed return.
• No revenue share.
• No profit participation.
• No securities rights.
• No promise of future investment rights.

What is Mindling?

Mindling is a local-first operating layer for AI-assisted software work. It helps builders keep scope, context, evidence, review, and approval attached to the work that AI agents help produce.

What exists today?

Mindling has a working product with 34 published capability surfaces: the local app, issue intake and lifecycle, workflow guidance, agent routing, QA and review gates, and evidence-oriented closeout. It has been running its own development since May.

What is the immediate ask?

The immediate ask is a 90-day development sponsorship. The goal is to keep building, polish the demo path, prepare early-user onboarding, and turn a product that works for one builder into one that other builders can install, understand and try.

Is this an investment?

No. The current ask is sponsorship, not equity or repayment. Supporters are helping fund development and receiving an inside view, early updates, and early access as the product becomes usable.

What is still unproven?

External users, willingness to pay, final pricing, support burden, and the best first customer channel are still unproven. The 90-day sprint is designed to turn those unknowns into evidence.

Current Product Evidence

• 34 published capability surfaces; version 0.1.0, with 7 at beta and 27 advisory.
• Local-first by architecture, not by preference.
• Issue intake and lifecycle behavior.
• AI-assisted workflow governance: scope, routing, evidence, QA, review, and owner approval.
• Internal company model with 15 department manifests.
• 16 explicit governed agent profiles.
• 2,156 automated tests across 139 files.
• 353 development tickets, 257 commits and 111 pushes through its own governed source-control path.
• 4 automated actions blocked and 1 push refused — against its own author.

What The 90-Day Sprint Should Prove

• Whether the product can be explained clearly to people outside the build.
• Whether early users recognize the workflow pain.
• Whether a simple demo makes the value obvious.
• Whether someone besides the founder wants to use or sponsor the workflow.
• Whether the next step should be paid beta, continued sponsorship, advisor support, or a formal funding conversation.

This packet asks for development sponsorship and early support.

Supporters May Receive

• private progress updates;
• early access when the product is usable;
• demo walkthroughs;
• visibility into what sponsorship helped build;
• the chance to share workflow pain that may influence the roadmap;
• optional acknowledgement as an early supporter.

Supporters Do Not Receive

• equity;
• repayment rights;
• guaranteed financial return;
• revenue share;
• profit participation;
• investment rights;
• guaranteed future investment rights.

If a formal investment, advisor, revenue-share, or equity path ever becomes appropriate, it should be handled separately with proper legal structure. That is not what this sponsorship packet is offering.