PRODUCTION SYSTEM
Agent-native CRM
A CRM designed and shipped solo, from scratch, with a native in-app agent that works through scoped tools and retrieval over workspace records.
Employment work. Architecture only; the company owns the code.
MECHANISM
Agent-native, not agent-adjacent
The in-app agent works through scoped tool access and retrieval over workspace records. The application decides what the agent may do and which records it may see, so permission is a property of the system rather than a promise in a prompt.
- REQUEST A person or the agent the agent is a user of the app, not a sidecar
- APPLICATION React and TypeScript the workflows live inside the app
- SCOPE What this agent may do tools and records granted by the application, not the prompt
- SERVICES Deno edge functions campaign automationemail stack
- DATA Supabase Postgres workspace records, with retrieval over them
SCOPE OF THE BUILD
Built as one system
TypeScript, React, Supabase and Deno edge functions, including campaign automation and a full email stack. The workflows that matter to the business live inside the application rather than being handed to disconnected services that then have to be reconciled.
HOW IT WAS COUNTED
A number with its method
~110,000 is 114,244 non-blank, non-comment lines across TypeScript and TSX files, with lockfiles and generated types excluded (126,355 raw). An earlier figure of ~55,000 had no recorded method; re-measuring with this one corrected it upward.
IN AN INTERVIEW
The two-minute walkthrough
-
0:00
Name the boundary first: employment IP, so no code and no screens.
A boundary an employer will need respected too.
-
0:20
Walk the diagram from request to record.
Where permission lives: in the application, so the agent cannot talk its way past it.
-
1:00
Give the line-count method, not just the number.
A number with a method can be checked, and this one was corrected by re-measuring.
-
1:30
For anything visual, switch to the live storefront.
Same author, same stack family, publicly visitable.