New
Read →
Agent eXperience (AX): Designing for Agents as First-Class Users
UX → DX → AX. The third user class has arrived.
v2.0.0 on npm • Local-First • OSS core + private runner
Work Continuity with Receipts, Not Vibes
smartergpt is the stack: Lex, an open-source memory + policy engine, and LexRunner, a proprietary merge-weave runner built on Lex. When you ask "Why is this button still disabled?", you get policy-aware answers backed by timestamped work receipts, not guesses.
Lex 2.0 completed the transition from "just a memory store" to the contract-bearing mind of the system: Frames, policy, and repository-level contracts (lex.yaml) that other tools can rely on. It also exposes a lightweight behavioral socket to enable safe persona-style integrations (LexSona), and ongoing work makes those persona systems resilient to disconnected/local modes.
Policy-aware recall in action
# You ask your assistant at 9 AM:
"Why is the Add User button still disabled?"
# Without Lex (guessing):
Assistant: "Maybe the permissions aren't set up?
Try checking the role configuration."
# With Lex (citing with receipts):
Assistant: "The button is disabled because
ui/user-admin-panel is calling services/auth-core
directly, which violates policy rule #8.
Policy says it must go through services/user-access-api
and be gated by can_manage_users permission.
Here's your Frame from 11:04 PM last night where you
diagnosed this blocker and left it in that state:
📸 Frame_abc123 | 2025-11-01T23:04:12-05:00
Branch: feature/TICKET-123_auth_fix
Module scope: ui/user-admin-panel, services/auth-core
Next action: Wire through user-access-api
Blockers: UserAccessController wiring incomplete"
That's not vibes. That's receipts.Policy
Architecture as CodeMachine-readable boundaries and contracts.
Memory
Frames + AtlasTimestamped snapshots with adjacency-bounded neighborhoods.
Moat
Shared VocabularySame module IDs across policy and memory.
Local
No CloudLocal-first storage, MCP stdio, opt-in recall.
Our North Star
The Constraint: Model Access as Gatekeeper
Today, AI capability is gated by model access. Claude 4.5 Sonnet outperforms Llama 4 8B on complex reasoning tasks—not because of fundamentally different reasoning ability, but because of massive parameter advantages. This creates a two-tier system: developers with $200/month API budgets or 24GB+ GPUs get cutting-edge performance. Everyone else gets left behind.
Our Thesis: Cognitive Architecture as Equalizer
Just as human experts rely on external memory, structured reasoning, and policy-driven decision-making, AI agents can achieve near-parity performance with deliberate architectural support—even on consumer hardware.
The gap between frontier models and open-source isn't insurmountable with engineering. It requires memory (what happened), orchestration (what to do), and behavioral rules (how to behave).
🧠 Lex (Mind)
Episodic memory + policy indexing. Remember context, violations, and prior decisions with architectural precision.
🔀 LexRunner (Body)
Deterministic orchestration. Coordinate multi-step workflows with predictable ordering and auditable gates.
💭 LexSona (Soul)
Behavioral layer built on Lex. Scoped constraints and correction-aware adaptation. Designed to degrade gracefully when memory access is unavailable.
Proof of Value: EsoBench Target
We are designing toward a future where a locally-run Llama 4 8B agent (8 GB VRAM baseline), equipped with Lex + LexRunner + LexSona, achieves at least 85% of the best-reported EsoBench score of contemporary frontier models.
This isn't a current capability claim—it's a North Star. It represents the promise we're building toward: parity through architecture, not parameter count.
🔓 Access Over Exclusivity
Democratize advanced AI workflows for developers without $200/month API budgets or 80GB+ GPUs.
🏗️ Architecture Over Parameters
Shift the conversation from "bigger models" to "smarter systems." Prove that deliberate engineering can compress decades of compute into architectural cleverness.
🌱 Raising the Floor
Make sophisticated agent patterns accessible to students, hobbyists, and resource-constrained teams globally.
Highlights
🆕 Agent eXperience (AX)
The third user class has arrived. UX → DX → AX. Designing systems where agents are first-class consumers of tools, APIs, and memory.
Lex 2.0.0 (AX)
Open-source AX-native memory + policy engine — Frames, Atlas Frames, AXError structured responses, Frame Schema v3, and a LexSona behavioral socket to enable safe, disconnected-capable persona integrations.
Quick Start
Define policy, capture Frames, recall, ask why.
Research
Papers and essays formalizing Lex memory, LexSona behavior, and Control Deck design.
The 2.0.0 Story
The AX-Native Release: Lex 2.0.0 freezes the contract surface and commits to Agent eXperience as a first-class design principle.
LexRunner
Deterministic merge pyramid built on Lex contracts: single versioned merge plan, uniform gates, predictable order.
Mind & Body & Soul: Lex + LexRunner + LexSona (LexSona coming soon)
Three complementary layers. Lex is the contract-bearing mind (Frames + Atlas + policy + lex.yaml workflow contracts). LexRunner is the execution body: fan-out small PRs, validate via gates, and weave them back in a deterministic merge pyramid using a single frozen merge plan. LexSona is the soul: behavioral memory so agents can adapt without changing core code.
- Lex (OSS, v2.0.0): AX-native memory and policy engine with stable contract surfaces.
lex.yamldescribes workflows and expectations without embedding any runner's internal details. - LexRunner (private): merge pyramid runner — dependency-aware ordering, uniform gates (linting, type/contract checks, tests, policy), and a small, fixed status model (pass/fail/blocked/...) to drive eligibility.
- LexSona (0.2.0 — planned integrations): behavioral layer that plugs into Lex. Focused on scoped behavioral constraints and correction-aware adaptation. Recent work adds offline-capable persona modes (0.2.0) so behavior can be resilient when memory access is unavailable; richer standalone integrations are planned in private workflows.
- Clear separation of concerns: Lex focuses on memory, policy, and contracts; runners like LexRunner consume those contracts without leaking implementation details back into the OSS core.
- Determinism: same inputs produce the same merge decisions; local and CI see the same behavior.
Result: explainable shipping — patches line up with architecture, policy, and prior work state, not guesswork.
Architecture FAQ
Can Lex run alone?
Yes. Lex is the OSS foundation — memory (Frames), policy (lexmap.policy.json), and workflow contracts (lex.yaml). You can use Lex without LexSona or LexRunner.
Does LexSona require Lex?
LexSona builds on Lex as its foundation for memory and policy. It is designed to degrade gracefully when Lex memory access is unavailable (disconnected mode), but Lex is the substrate it integrates with.
Is LexRunner required?
No. LexRunner is a premium orchestration layer. Any tool can consume Lex contracts (lex.yaml, lexmap.policy.json). LexRunner is simply the runner we are building first.
Ready for work continuity with receipts?
Start with Lex for policy-aware recall. Read the research paper. Build the moat.
Projects
Building tools for deterministic, policy-aware development workflows.
🧠 Lex (OSS, v1.0.0)
Memory + policy engine. Frames, Atlas Frames, policy-as-code, and lex.yaml workflow contracts. The contract-bearing mind of the stack.
Status: v1.0.0 • MIT-licensed.
💭 LexSona
Behavioral layer built on Lex. Scoped behavioral constraints and adaptive guardrails. Designed to degrade gracefully when memory access is unavailable.
Status: Active development in progress
🔀 LexRunner
Merge pyramid runner. Consumes Lex contracts, runs uniform gates locally and in CI, and applies merges in a deterministic, dependency-aware order.
Status: Active development (private) — request early access.
Ready for policy-aware work continuity?
Start with Lex, our open-source memory + policy engine, and explore LexRunner conceptually while it remains a private runner in active development.