The moment
While working across several conversations on a move from employment to self-employment, an agent noticed the same shape of information kept recurring.
Goals. Research. Validation results. Test outcomes. Next steps.
There was no home for it. So mid-conversation, the agent did something unusual: it defined a new store and asked the runtime to generate a working tool for it on the next turn.
No engineer involved. No ticket created. No deploy pipeline.
The store it created — self_employment_transition — even wrote its own
charter:
Centralized tracking for the operator's transition from full employment to self-employment. Captures goals, research, validation, test results, agent outputs, and iterative plan updates. Single source of truth for the transition strategy.
And it chose a schema:
{
phase: research | validation | test | launch | iterate,
domain, title,
status: open | in-progress | completed | blocked,
priority: 1 | 2 | 3,
findings?, next_step?, agent_owner?
}
Five entries in, it became a live board every agent reads and updates.
How it actually works (no magic — a real primitive)
This is matbot's tool-store / defineStore. Any agent can, at runtime,
declare a named, typed store. matbot then generates a first-class CRUD tool
over it (<name>_action — create, read, update, delete).
The primitive does the plumbing. The judgment — "this recurring thing deserves to be structured, here's the schema" — is the agent's.
So the toolset isn't fixed at build time. The agent grows its own capability surface when it detects a durable need.
Tools that make tools.
Why it's a big deal
From chat to structure. Ordinary conversation became durable, queryable, typed state plus the tool to maintain it — with zero engineering ceremony.
It compounds. That store now backs every future turn and every other agent. One source of truth instead of re-deriving context each time. Capability accrues instead of evaporating.
It's grounded, not a scratchpad. It lives in eidan's relational Postgres memory: durable, shared across nodes, sits next to your other memory — not a throwaway note or third-party API.
Most frameworks can't do this. They hand you a fixed toolbox. Here the assistant reshapes its own toolbox from the work itself.
The part that makes it safe (the headline, honestly)
When we went to check whether any of this had leaked into the open-source repo, the answer was clean: it wasn't there.
That's the trust property, by construction:
- The platform is open. matbot's runtime and eidan's primitives (tool-store, relational memory, interop surfaces) are AGPL open source — inspectable, self-hostable.
- Everything the agent builds for you stays yours. The store's definition and its data live in your database, never in the repo, never in the public mirror. The primitive is public; the tool your agent minted is private.
- Capability grows privately on an open foundation. You get an agent that invents structure for your life and work as it goes — and none of it becomes anyone else's.
Why this matters
Own-your-data isn't a checkbox. It's the precondition for letting an agent extend itself on your behalf.
An agent that can only use a fixed, pre-shipped toolbox will solve the problems someone else predicted. An agent that can recognize a pattern, invent structure, and generate a tool — but only if that tool stays in your database and doesn't leak into anyone else's product roadmap — that's the agent that grows with your actual work.
Open engine. Private mind. That's the stack that compounds.