The basic idea is simple to explain, but hard to prove:
Can an AI coding agent work under an engineering methodology—not only a task prompt, a Markdown instruction file, or a lint configuration?
By “methodology,” I mean more than code style:
- Engineering philosophy.
- Trade-offs.
- Architecture boundaries.
- Preferred implementation patterns.
- Anti-patterns.
- Tool usage habits.
- Validation behavior.
- Review expectations.
- Evidence from previous outcomes.
I call that package a Mind.
A Mind is intended to be a versioned, executable engineering methodology that an AI coding agent can use while planning, coding, using tools, validating changes, and preparing a pull request.
The problem I’m trying to solve
AI coding agents are increasingly capable of reading repositories, editing files, running commands, writing tests, and opening pull requests.
But producing code is not the same as making the decisions an experienced team would make during review.
For example, an agent may:
- Add a dependency when an approved internal utility already exists.
- Create a new service instead of extending the existing domain boundary.
- Add an API endpoint without updating tests or documentation.
- Solve tenant isolation with application-level filtering rather than the repository’s intended database policy.
- Pass type checks while violating an architectural convention that reviewers repeatedly enforce.
Current tools help, but each covers only part of the workflow:
AGENTS.md / CLAUDE.md / Cursor rules
→ communicate repository instructions
Skills
→ package reusable workflows and knowledge
MCP
→ provides access to tools, resources, and prompts
TypeScript / Biome / ESLint / Semgrep / tests / CI
→ verify specific technical conditions
The question behind LMP is whether these can be coordinated around a single versioned engineering methodology profile.
What LMP is trying to add
The core contract is:
One Mind → guidance + verification + evidence
A selected Mind is compiled into:
Engineering Mind
↓
Task-scoped agent instructions
↓
Typed repository context
↓
Tool and command boundaries
↓
Evaluation plan
↓
Bounded remediation loop
↓
Redacted evidence artifact
↓
PR-ready validation summary
So the agent does not just receive advice like:
“Avoid unnecessary dependencies.”
It can receive an operational policy:
1. Inspect package.json and existing platform utilities.
2. Do not add a new runtime dependency without rationale.
3. Run dependency-diff validation.
4. If the policy fails, return a structured finding.
5. Fix the finding, document an exception, or escalate.
6. Record the outcome in an evaluation artifact.
What currently exists
The repository is early, but it is not only a concept document.
Current surfaces include:
TypeScript packages:
- CLI
- Core
- Evaluator
- Registry
- Skill schema
- Skill compiler
- MCP server
- Initializer packages
Protocol-core Rust crates:
- lmp-core
- lmpd
- lmp-mcp
- lmp-sync
Profiles / skills:
- baseline
- typescript-minimal
- initial methodology/profile definitions
Other surfaces:
- test fixtures
- examples
- benchmark/orchestration scaffolding
- local registry work
- documentation
- CI/release files
- agent discovery folders for Skills
The intended local-first workflow is deliberately boring:
lmp init --baseline
lmp evaluate
The default path should not require Docker, a daemon, OCI, IPFS, signatures, MCP setup, uploads, or network access.
Advanced protocol components can remain optional:
Daemon
MCP
Ed25519 signing
OCI distribution
Docker sandbox
Remote artifact sync
Fleet / multi-agent orchestration
What this is not
I do not want to claim that LMP:
- Clones a person.
- Reproduces someone’s private reasoning 1:1.
- Trains model weights automatically.
- Guarantees secure or production-ready code.
- Replaces human review.
- Replaces existing Skills, MCP, linters, tests, SAST tools, or CI.
- Proves architecture or security from static analysis alone.
The stronger claim I want to test is:
LMP may help an AI agent make decisions more consistent with a chosen engineering methodology, while producing explicit evidence of what was checked, what failed, what was skipped, and what still needs human judgment.
The part I’m most unsure about
I know the obvious criticism:
“Isn’t this just AGENTS.md + Skills + MCP + ESLint + CI with extra complexity?”
That is a fair question.
If LMP only produces a larger prompt or duplicates lint rules, then it is not useful.
The only reason it should exist is if it can prove that this flow catches meaningful, repository-specific issues before human review:
Agent generates patch
↓
LMP evaluates against active Mind
↓
Agent receives concrete remediation
↓
Agent fixes objective failures
↓
Human reviewer sees remaining trade-offs and evidence
How I plan to test it
I want to compare two controlled workflows:
Same repository
Same task
Same model
Same coding agent
Same tool permissions
Same starting commit
Run A
Existing instructions + Skills/rules + lint + tests + CI
Run B
Same setup + active LMP Mind + evaluation/remediation loop
Then measure:
- Meaningful review findings.
- Rework after review.
- Missing tests.
- Dependency-policy violations.
- Architecture-policy violations.
- Type/lint/security findings caught before PR.
- False-positive rate.
- Evaluation overhead.
- Setup effort.
- Reviewer time.
- Number of remediation loops.
I do not have benchmark results yet. This is currently an implementation and research hypothesis, not proof.
I want brutal feedback
I’m posting this because I would rather discover the weak parts early than build a large system nobody needs.
I’d value input on:
- Is the distinction between a Skill and an executable Mind meaningful?
- What would make this useful beyond
AGENTS.md, existing agent rules, and CI?
- Which engineering rules repeatedly appear in your code reviews but are hard to automate today?
- What would you benchmark first?
- What would make you distrust this system?
- Would you use a local-first evaluator that generated an evidence artifact for agent-created changes?
- Which part feels redundant, overbuilt, or technically wrong?
I’m especially interested in feedback from platform engineers, maintainers, staff/principal engineers, security engineers, DevEx teams, and people who review a lot of AI-assisted pull requests.
The project is called Lending-Mind Protocol:
Deterministic guardrails for AI-built software.
My goal is not to make agents “sound senior.” It is to make engineering methodology, verification, and uncertainty explicit enough that agents can be held accountable to the standards a team actually cares about.
Is this an actual missing layer for AI coding agents or just a complicated way to recreate tools we already have? I want the honest version.
