Andrew Crenshaw

Portfolio · Agentic Engineering

Built,
not theorized.

Enterprise AI Architecture & Engineering

I design and build custom AI products: multi-agent systems engineered with enterprise rigor to solve hard problems and hold up under load.

25 years · dot-com to enterprise to AI $250M pipeline · 5,000-user platforms multi-agent systems built and running unified data → decision support at scale

What I've built

01 / WORK

Every system below I built myself, end to end: architecture and code, down to the working software. Different domains, same architecture spine: multi-agent collaboration, under governance, over shared memory.

Flagship

Living Memory & Knowledge System

I designed and built an agent-memory substrate: a lens-projected, provenance-tracked knowledge store where each session captures decisions and lessons that surface to the next, running on my own development fleet. Cross-session retrieval is live. The hard part is deciding what to keep, so the compounding-quality layer (forgetting, reweaving, and conflict resolution) is in active build.

Model & mechanics
Running on my own fleet: Forge (TypeScript / Node / SQLite) and Strata (Python / FastAPI / Postgres + pgvector)
Decision traces: a durable, queryable record of what was decided, why, and what was rejected (2,200+ lessons and traces captured)
Token-budgeted, lens-filtered retrieval, so the right knowledge reaches the right agent at the right moment; cross-session retrieval is live
A session digest (reduce, reflect, archive) runs after each session
In active delivery: the compounding loop (reweaving, conflict resolution, and forgetting: pruning, supersession, stale-detection)
Deep dive: Living Memory & Alexandria →
Flagship

autogenous-synthesis Forge

I built a development operating system where twelve specialized agents plan, build, review, and ship code against a live backlog state machine. Agents claim work, hand off across phases without losing context, and nothing clears a phase without passing a mechanically-enforced review gate. It runs end to end on its own; I keep a single human-in-the-loop surface, deciding which work dispatches in what sequence, by design.

Stack & mechanics
12 specialized agents, auto-routed and skill-aware, with collision detection and bounded authority
TDD enforced mechanically (RED → GREEN → REFACTOR) against machine-verifiable acceptance criteria
Review gate: lint + 700-test suite + Eval + code review + pre-commit, run on every ticket before it can close
Persistent scratchpads and session memory survive context limits; phase handoffs run without a restart
TypeScript / Node.js  ·  SQLite
autogenous-synthesis.com ↗ Documentation ↗ Deep dive: Forge architecture →

Strata

An autonomous job-search system, built in the open and running in alpha on my own infrastructure: eight agents, three-layer deduplication, fully local inference.

Details
8 agents · 3-layer dedup · local inference (Qwen via oMLX) · PostgreSQL + pgvector · ARQ + Redis · open-source PyPI libraries. Running in alpha on local infrastructure (incl. local LLMs); shared as an engineering reference.

Local AI Infrastructure

A four-machine Apple Silicon cluster running open models entirely on-prem, keeping inference private and cost-free at the edge.

Details
Qwen3.6 35B MoE, 27B Dense, 2B · snowflake-arctic-embed · oMLX · 245–326 tok/s · 91.9% TruthfulQA

Customer Contextualization Framework

Identity resolution unifying CRM and behavioral data into a single, trustworthy customer view.

Details
Identity resolution · SSOT · CRM + behavioral data · Salesforce custom objects · AWS Redshift · Builder.io · Ada chatbots

Enterprise Workflow Automation

Salesforce and Jira integration with end-to-end test traceability across the delivery loop.

Details
Salesforce (MCP + CLI) + Jira + Confluence integration · automated test traceability

HR Media Campaign Platform

A platform generating personalized video campaigns from text, wired into Slack and SSO.

Details
Node.js / Express · PostgreSQL · Google TTS + HeyGen · Slack · SSO

niKi: Now I Know It

A proof-of-concept AI learning platform built on knowledge graphs.

Details
Knowledge-graph architecture · 8 built-in skills · prototype / POC
02 / Approach

Built to weather production use

My path runs the full arc of the commercial internet. I started in the early dot-com era, building digital products when the web itself was new and shipping fast and innovating relentlessly were the only rules. I spent the next two decades inside the enterprise: global CRM for 5,000 users, multimillion-dollar technology budgets, and the security, audit, and compliance requirements that do not bend.

Now I take that enterprise substrate, the hard-won discipline of architecture, governance, and durability, and apply it to custom AI products. I believe that combination is rare. Startup speed without enterprise scar tissue produces demos that collapse under load. Enterprise rigor without builder instinct produces strategy decks that never ship. I do both, which is why what I build solves hard problems and is architected to last.

Full 25-year career history → The sources I build on →

Memory is the multiplier. Agency is the force.

03 / THINKING

Without memory, agency does the same work repeatedly. The difference between agents with a vector database and agents with a memory system that compounds is the difference between a tool and a team.

But more memory is not better memory. Storing what is stale or simply wrong is worse than storing nothing, because agents act on it with confidence. Memory has to curate: reconcile, prune, and forget.

Speed without governance means fast in the wrong direction. Every agent runs with bounded authority, continuous approval gates, and automatic audit trails.

Most memory products stop at retrieval. The layer that matters is one substrate that remembers across systems, with role-shaped lenses on top and transient task frames inside.

Retrieval

Right knowledge, right agent, right moment

Personalization

Learning

Reduce, reflect, consolidate

Most skip this

Storage

Where knowledge lives

Infrastructure

And the interpretation model underneath it: substrate / lens / frame.

Substrate

One shared memory: the universal state every agent reads and writes

Ground truth

Lens

A persistent, role-shaped filter onto the substrate

Per role

Frame

The transient task binding, gone when the work is done

Per task

view = render(substrate, lens, frame)

From my own fleet to a protocol

04 / SLF

Substrate, lens, and frame run my own systems today. The harder question is what happens when the agent acts for a person: across organizations, and over years.

SPA (Sovereign Personal Agent) and SLF (the Substrate / Lens / Frame protocol) take the memory model behind those systems and ask who it should answer to. A person owns the substrate. Organizations and regulators read it only through the lenses they are granted. An agent acts on the person's behalf, not in place of them, and every access leaves a receipt you can audit later.

The substrate is built and running, as Living Memory and Alexandria. SLF and SPA are the protocol I'm proposing on top of it: the grant semantics, the audit receipts, and the recovery path are designed and written up, not yet shipped. The position paper sets out the gap and the approach, and I'd welcome the people best placed to pressure-test it.

render(substrate, lens, frame) → receipt

Let's talk

What should we build?

I'm open to collaborating in whatever shape fits, as peer, partner, leader, or pupil. If you're building, researching, or thinking hard about agentic systems and how they meet enterprise complexity, I'd like to hear from you.