Membrane — Proof of Concept
How the architecture builds in practice, today.
The Developer Interface
The developer's entire input to the membrane is a function marked as external.
from membrane import external
@external
def get_user_info(user_id):
...
@external
def search_deal_flow(query):
...
No capability spec. No API definition. No documentation. No permissions model. Just the function, marked. Everything else is derived.
The membrane package does two things:
build time — tells the tool which functions are exposed
runtime — provides the call bridge so System Presence
can invoke the function directly
System Presence calls the exposed functions directly — not through HTTP, not through routes. Whatever server or framework the developer uses for their own purposes is invisible to membrane. The inner system stays untouched. Just functions that do what they do.
Language agnostic. The tool reads whatever is there. The package convention is the same across languages — only syntax differs.
MIM — Model, Intent, Membrane
The programming paradigm that membrane makes possible.
Model — DB, data, storage
Intent — capability functions, business logic
Membrane — everything else
The developer writes M and the raw functions of I. The meaning of I — the business logic — belongs to the business; System Presence extracts and composes it; the developer only helps where the code is ambiguous. Membrane is M(embrane). (Today, while semantics is still load-bearing, the developer remains the guardian of that intent — the full handover lands with the semantics-free intent language.)
Model is the database. Raw data. Knows nothing about what the outside world wants or why. It holds companies, deals, valuations, users, history. It answers queries. Nothing more.
Intent is the capability layer. This is where business meaning lives. Not routing, not interface, not storage — just what this system can do, expressed with full business context. An intent knows which data it needs, what the business rules are, how to compose a result that means something.
Membrane is the rest. Guardian generates the surface and receives the outside world. The membrane routes, enforces, and protects. System Presence understands the Intent layer and calls it. The developer writes none of this.
Example — a deal flow system:
Model holds companies, funding rounds, valuations, dates, investor notes. Plain data. Queryable.
Intent holds what the system can actually do with that data:
companies_dropped_valuation
scope: company.deal_flow = active
filter: round[-1].valuation.post < round[-2].valuation.post
returns: company, delta(valuation.post), round[-1].date
order: delta ASC
company_decision_snapshot(company)
depth: rounds[-3..]
returns: rounds, valuation.current, round.lead_investor
notes where flagged = true
excludes: notes where nda = true
flag_company(company, reason)
writes: note { company, author = caller, flagged = true, reason }
requires: reason
investor_activity_quarter
scope: round.date within current_quarter
group: round.lead_investor
returns: total_deployed, deal_count, sectors
Membrane receives whatever the outside world sends — a natural language question from a partner, a structured query from another AI agent, a call from an integrated tool. It routes to the right Intent. It enforces who can ask what. Guardian tells the outside world these capabilities exist and how to reach them. System Presence calls the Intent functions and returns the result.
The developer wrote the data model and the intent functions. Nothing else.
Membrane as VC
In any MVC system, something has to own routing, interface, and presentation. That is why MVC exists.
Membrane takes those concerns entirely.
Model — inner system
data, logic, capabilities
all that remains
View — Guardian
the outward surface
how the system presents to the world
Controller — System Presence + Membrane
receives intent, routes, executes
calls the Model, returns the result
The developer writes M. Membrane is VC.
Every developer who knows MVC immediately understands their job: write the Model. The VC layer is generated, trained, and maintained by the three machines. Routes, controllers, interface, authentication, documentation — none of it is the developer's problem.
Two modes:
Existing system — System Presence reads the existing MVC structure as-is. It understands routes, controllers, models — whatever is there — and calls them directly. The inner system does not change. The membrane wraps what exists. Any backend, any framework, any language.
New build — starting from scratch with membrane means MVC is unnecessary. The controller layer collapses. The view layer collapses. What remains is pure capability functions — no routes, no middleware, no HTTP concerns, no auth layer. The developer writes business logic. Nothing else.
How Intent Is Extracted
The developer does not define intent. Intent is extracted.
System Presence reads the inner system — code, structure, data models, functions. For most of what it finds, it derives the logic directly. A read-only function that returns a single record does not need to be explained. The code is the evidence. System Presence writes the rule and moves on.
For what the code cannot resolve — business decisions, scope boundaries, policy choices that live in the developer's head and not in the implementation — System Presence asks.
The interaction is inverted. System Presence questions the developer. Not the other way around.
What gets derived silently:
function reads a single record → read rule, no question
function takes no write parameters → read-only, no question
function scoped by user argument → caller-scoped, no question
function calls no other functions → no side effects, no question
The obvious is never asked. System Presence asks only where the code is genuinely ambiguous — where two valid interpretations exist and the choice is a business decision, not a technical one.
What gets asked:
System Presence: "get_user_info takes a user_id. Should it return
any user's record or only the caller's own?"
Developer: "Own record only."
System Presence: "search_deal_flow has no result limit in the code.
Should there be one?"
Developer: "Yes, 100 results. Paginate beyond that."
System Presence: "flag_company writes a note. Is this reversible?"
Developer: "No."
Short questions. Specific. One decision at a time. The developer answers in plain language. No schema, no spec, no format to learn.
Answers compile to rules:
The developer's answers are not stored as text. They compile immediately to the intent language. Hard logic. Deterministic. Not subject to reinterpretation.
% "own record only"
get_user_info(Caller, Data) :-
user(Caller, Data),
owns(Caller, Data).
% "100 results, paginate beyond that"
search_deal_flow(Query, Results) :-
deal_flow_match(Query, All),
length(All, Len),
( Len =< 100 -> Results = All
; length(Results, 100), append(Results, _, All) ).
% "not reversible"
flag_company(Company, Reason, Caller) :-
assert(note(Company, Caller, flagged, Reason)),
\+ retractable(flag_company).
The developer never sees this. They answered a question. System Presence wrote the rule.
Memory:
System Presence remembers every question asked and every answer given. When new code is added, it reads the existing rule base first. If the new function follows a pattern it already understands — same scope, same access model, same reversibility — it derives silently. No question.
First function: three questions
Tenth function: one question
Hundredth: System Presence derives silently, confirms once
Questions arise only at the edges of what is known. As the system grows, the questions become fewer. System Presence learns the developer's intent model and applies it forward.
The Intent Language
The output of the questioning process is a purpose-built interpreted language. Not Prolog exactly — a language designed specifically to express intent, generated by System Presence and never hand-written by developers.
Interpreted. Rules are evaluated at runtime directly against the Model. No compilation step, no intermediate representation, no bytecode. The rule definitions are the source of truth. The evaluator runs them live against whatever the data holds right now. Rules can be hot-swapped without recompiling anything. What ran is always inspectable — the rules are readable.
Prolog-like at the evaluation level. Resolves rules through unification and deterministic clause resolution. Same input, same output, always. But scoped entirely to intent — no general-purpose programming, only the constructs the language defines.
The constructs:
scope — what universe this runs against
preconditions that must hold before evaluation
filter — logical conditions that must hold
narrows the result set
returns — what comes back and how it is shaped
the output contract
excludes — hard constraints
what never crosses regardless of other conditions
requires — input validation
what the caller must provide
writes — side effects, explicit and declared
nothing implicit, nothing hidden
group — aggregation over a result set
order — result ordering
The evaluator resolves these rules against facts in the Model. That is the only thing it does. It has no knowledge of Guardian, Membrane, or System Presence. It takes a rule and a data context. It returns a result or it does not.
The language has no name yet.
The Build Tool
One command. Point it at source.
membrane src/
What it does:
1. scan for exposed functions
2. System Presence reads the inner system
3. System Presence briefs Guardian through the membrane
4. calibration runs — all three surfaces
5. homeostasis reached
6. the Forget
7. artifacts generated
8. deployment package produced
What it produces:
membrane model — trained path artifact
Guardian definition — generated, operational
System Presence def. — generated, operational
orchestration config — wires the four layers together
blue-green infra — shadow membrane, switching logic
The developer's inner system is unchanged. The deployment package wraps it entirely. The external interface is no longer the inner system's own surface — it is Guardian. The inner system is never directly reachable.
What the Pipeline Derives
System Presence reads the exposed functions and derives the full capability model. The developer does not write this. It is a pipeline output, not a pipeline input.
┌─ CAPABILITY ──────────────────────────────────────────┐
│ name: search_deal_flow │
│ permitted: read only │
│ scope: caller's data only │
│ intent types: [QUERY, DISCOVER] │
│ not permitted: [EXECUTE, DELEGATE, DELETE] │
│ rate: 100/hour │
│ audit: every call logged │
└───────────────────────────────────────────────────────┘
This is what calibration runs against. This is what the membrane enforces. Not what the developer specified. What System Presence understood.
No runtime override. No "just this once."
Running It Today
The architecture requires a specific substrate for each entity. Today, software equivalents exist for all three.
Guardian — LLM API call
exists today, runs on cloud inference
Membrane — trained model artifact
ONNX inference on CPU, fast enough for routing
System Presence — LLM API call with persistent context store
exists today, accumulates across sessions
The software equivalents replicate the architecture's behaviour. Not the same substrate — the same effect.
The membrane is the entity that eventually wants dedicated silicon. It sits in the hot path on every request, needs sub-millisecond routing, and its learning model — path-forming, Hebbian, structural — maps directly to neuromorphic chip design. On dedicated silicon it never touches general-purpose compute, learns natively without a training cycle, and the rebuild pipeline disappears.
Guardian and System Presence are LLMs. They run on whatever inference hardware the model providers run. No custom silicon required.
Membrane Versioning
The architecture requires the membrane to adapt continuously from what flows through it. How that adaptation happens is an implementation detail, not a design dependency.
Now — rebuild and ship:
live traffic
│
▼
logs accumulate
│
▼
rebuild membrane on accumulated signal
│
▼
validate — homeostasis reached, no regressions
│
▼
ship — hot-swap, old membrane retires
The live membrane is frozen between rebuilds. Logs are the feedback signal standing in for real-time weight updates. The rebuild cycle is the recalibration loop running on production data instead of synthetic scenarios. Same outcome — continuous adaptation — at a slower cadence with a validation gate before each ship.
The lag between a new pattern appearing in production and the membrane adapting is the current limitation. The validation step is the current strength — a candidate membrane that forgot valid paths or reopened closed ones fails homeostasis and does not ship.
Later — faster recalibration, never self-adaptation:
Neuromorphic hardware makes the rebuild cheaper and the cadence tighter — recalibration that takes a pipeline today could run near-continuously in the background on dedicated silicon. What it does not do is let the membrane rewire itself unsupervised. The serving membrane stays frozen between recalibrations; the two intelligences still decide when it changes, and a validation gate still stands between a candidate membrane and production. An unsupervised, self-adapting gate is exactly the surface this architecture exists to remove — making it faster to rebuild is the goal, making it adapt by itself is not.
The completeness target, the homeostasis requirement, and the validation gate stay. Only the cadence tightens — from rebuild-and-ship to near-continuous recalibration.
Pim Bongers, Studio Bonkers, June 2026 With Claude