Agent Micro-app Generation
The agent does not call tools. The agent creates tools. The model becomes a compiler. WASM generation sprint archived; capability-lineage research active.
Agent Micro-app Generation
The concept
The agent does not call tools. The agent creates tools.
The model becomes a compiler.
Current agent model:
User request
|
v
Agent reasoning
|
v
Choose existing tool
|
v
Execute tool
Agent Micro-app Generation:
User request
|
v
Agent reasoning
|
v
Generate program
|
v
Compile to WASM
|
v
Execute sandboxed binary
|
v
Return result
The output is not text. The output is a tiny executable.
Example
User:
“Convert these 500 CSV files into normalized JSON and remove duplicates.”
Traditional agent:
call python tool
write script
run script
inspect errors
fix script
run again
Micro-app agent:
Generates:
csv-normalizer.wasm
size: 380 KB
Containing:
- CSV parser
- normalization rules
- deduplication logic
- output formatter
Runs it.
Deletes it afterward.
The “tool” only existed for that task.
What was built (exploratory sprint, March 2026)
A 3-day exploratory sprint. The goal was to test whether an LLM could generate, compile, and execute small WASM-based tools on demand. The sprint produced:
- A task-description DSL (limited)
- A Python-to-WASM compilation pipeline (via
wasmpy) - A runtime that loaded and executed generated WASM modules
- A sandboxed execution environment
The sprint produced generated WASM that was correct for simple tasks (arithmetic, string manipulation) and broken for anything real.
Why WASM is the key
Sandbox
The generated program cannot casually:
- access your filesystem
- open network sockets
- modify your system
unless explicitly granted.
Portability
Same binary:
Windows
Linux
macOS
Browser
Edge device
Speed
Instead of:
LLM
|
thousands of tool calls
|
slow orchestration
you get:
LLM
|
generate optimized worker
|
native-ish execution
The connection to CSM
CSM solves:
“What does the agent remember?”
Micro-app generation solves:
“What does the agent become capable of right now?”
Together:
CSM
|
v
Agent Compiler
|
v
WASM Micro-App
|
v
Task execution
|
v
Lessons + artifacts
|
v
CSM
The agent could literally improve its own toolbox.
Example:
Day 1:
Agent:
"I need a better log parser."
Generate:
log-parser.wasm
Day 20:
CSM remembers:
Previous parser worked well.
Preferred regex strategy:
...
Common log formats:
...
New version:
log-parser-v2.wasm
The felicity problem
This is where the concept gets hard.
The issue isn’t generating WASM.
The issue is:
How do you know the generated executable is actually the right one?
A model can generate:
- syntactically valid code
- compilable WASM
- executable behavior
and still be wrong.
You need a verification loop:
Generate
|
Compile
|
Static analysis
|
Sandbox tests
|
Capability checks
|
Output validation
|
Accept/reject
Basically:
the agent needs a software engineering pipeline for its own creations.
The lesson from the sprint: LLMs are not compilers. They are pattern-matchers. Compilation requires specification; specification is the hard part.
The future version
User:
“Analyze my company’s quarterly reports and find unusual spending.”
The agent does not install an analytics package.
It creates:
quarterly-anomaly-detector.wasm
with:
- parser
- statistical model
- visualization generator
- report exporter
Runs it.
Stores:
artifact:
quarterly-anomaly-detector.wasm
lesson:
"Finance reports use this schema"
benchmark:
"97% accuracy on historical reports"
Next time it already has the capability.
Why this is potentially bigger than plugins
Plugins are:
Human creates capability
Agent uses capability
Micro-app generation is:
Agent creates capability
Agent uses capability
That is the jump.
It turns the agent from a user of software into a software generator.
The interesting combination would be:
- CSM = memory + continuity
- WASM generation = capability creation
- evaluation and governance = evidence + deployment control
That starts looking less like an assistant and more like a self-extending runtime. The hard part is not making the agent write code - models already do that. The hard part is making generated capabilities testable, traceable, reusable, and bounded by externally assigned deployment risk.
Governance primitives
This is a good stopping point because the remaining issues are no longer philosophical gaps - they are governance primitives. The thesis has stabilized.
The two notes below are exactly where the implementation would eventually hit reality.
Risk classification must be outside the generative loop
The risk classifier cannot be:
Agent:
"I made an invoice processor.
Risk: low."
because the risk decision itself is part of the capability.
The safer architecture:
Capability request
|
v
Static risk classifier
|
v
Autonomy policy
|
v
Agent generation allowed/limited
The classifier should be boring. Not intelligent. Something like:
{
"domain": "finance",
"actions": [
"read_invoice",
"modify_payment_state"
],
"risk": "high",
"autonomy": "approval_required"
}
Rules:
Filesystem read-only -> low
Filesystem write -> medium
Network access -> medium
Credential handling -> high
Money movement -> high
Medical recommendation -> high
Safety control -> critical
The irony is that the least “AI-like” part of the system may be the most important. A static rules engine is valuable because it does not share the model’s uncertainty.
Confidence needs to become evidence-backed, not a feeling
A score like:
deploymentConfidence: 0.91
is dangerous without a derivation.
It should probably be decomposed:
{
"confidence": {
"score": 0.74,
"components": {
"testCoverage": 0.90,
"realWorldValidation": 0.50,
"knownUnknowns": 0.80,
"failureRecency": 0.95,
"externalReview": 0.60
}
}
}
The final score is less important than exposing the ingredients.
A possible model:
confidence =
testCoverage * 0.25
+ validationHistory * 0.30
+ externalReview * 0.20
+ stabilityHistory * 0.15
- unresolvedUnknownPenalty * 0.10
The exact weights are debatable. The important rule:
No confidence value without an evidence trail.
The resulting capability object
Something like:
{
"id": "invoice-deduper",
"version": "3",
"intent": {
"humanRequest": "...",
"derivedGoal": "..."
},
"specification": {
"inputs": [],
"outputs": [],
"constraints": []
},
"artifact": {
"type": "wasm",
"hash": "...",
"size": "..."
},
"risk": {
"classification": "high",
"source": "static_taxonomy",
"requiredAutonomy": "approval"
},
"verification": {
"anticipatedRisks": [],
"testFailures": [],
"knownFailures": [],
"externalValidations": []
},
"confidence": {
"evaluatedScore": 0.74,
"lastEvaluated": "2026-07-11T20:00:00Z",
"decayPolicy": "csm_ebbinghaus_v1",
"components": {
"testCoverage": 0.9,
"validationHistory": 0.5,
"externalReview": 0.6,
"stabilityHistory": 0.8,
"unresolvedUnknownPenalty": 0.2
},
"evidence": []
},
"lineage": {
"parent": "invoice-deduper-v2",
"changes": [],
"lessons": []
}
}
Notice what is missing:
"correct": true
That field should not exist.
The system should record:
- what it believes
- why it believes it
- how it was challenged
- what happened afterward
The final research framing
Capability lineage is an engineering memory system for AI-generated software artifacts. It does not solve intent alignment or guarantee correctness; it provides provenance, risk-aware deployment control, and cumulative learning from capability evolution.
That is actually a stronger paper than the original “AI generates trustworthy tools” idea because it makes a clear claim that can be tested.
And it fits CSM naturally:
CSM already asks:
“What should an agent remember?”
Capability lineage asks:
“What should an agent remember about the things it creates?”
That is the same problem at a different layer.
Where the work is
WASM generation sprint: archived. The core loop (generate, compile, execute) was tested in March 2026. It worked for trivial tasks and broke for real ones. Autonomous generation remains archived until the intent-to-specification gap is better bounded.
Capability-lineage research: active. The immediate work is a versioned capability-object schema, external risk taxonomy, evidence-derived confidence model, and CSM-backed lineage storage. This layer can proceed independently of autonomous WASM generation.
Trustworthy autonomous self-extension: unsolved.