know what you built.
Architecture is Fizzgig’s record of your product as it actually is. Every decision your team locked in, every dependency you pulled, every platform you wired up, every plan you haven’t got to yet. It’s assembled by your AI editor while you work and by scheduled pulls from your connected platforms - so it reflects this morning’s state, not the state of things when someone last remembered to write a doc.
your product knows more than you do.
Everything you decided is written down somewhere. It’s in a chat history forty sessions long, in a commit message, in a Slack thread, in your head. Technically it exists. Practically it’s gone.
The cost shows up in three ways. You re-litigate a decision you already made properly six weeks ago, because nobody can remember why you ruled out the obvious option. A new person joins and takes a fortnight to learn things you could have handed them in an afternoon. Something appears in the stack that nobody remembers adding, and now you’re not sure whether it’s load-bearing.
Then someone external asks. What does the product depend on? Where is customer data stored? What happens if that vendor goes away? The honest answer is that you’d need to go and look - which is a bad answer to give an investor and a worse one to give a security reviewer.
Architecture is the answer to all of those, maintained continuously, by the agent that’s already in the room.
four things, always current.
memory_recordCaptures a decision at the moment it’s made, not in a write-up afterwards. When your agent settles on Neon over RDS, or picks a queue, or decides the auth model, that choice is recorded with the reasoning attached.
Your AI editor calls memory_record mid-session as part of the work. There’s no separate step and nothing for you to remember.
The decision, the alternatives that were considered, the reasoning, the timestamp and the files it touched. Semantic search across all of it, so “why did we do it this way?” is a question rather than an archaeology project. Decisions supersede rather than overwrite - you can see how thinking changed and when, which is often more useful than the current state alone.
stack_mapMaintains a categorised inventory of everything your product runs on. Vendors, libraries, APIs, protocols, data stores.
Detected from your code and cross-referenced against your connected platforms. Nothing is entered by hand.
Every entry carries its provenance and a confidence level - you can see why Fizzgig thinks something is in your stack, and how sure it is. That matters more than it sounds: it’s the difference between a map you trust and a list you’d have to verify. Drift shows up too. When something appears that no decision accounts for, it surfaces rather than sitting quietly in a lockfile.
plan_addCatches intentions before they evaporate. Every “we should do X next” that surfaces mid-session becomes a card instead of a thought you had once.
Your agent calls plan_add when a next step comes up in conversation.
A board of things you meant to do, each linked back to the decision that produced it. When a card ships, the link holds - so the plan doubles as a record of how the product actually developed, not just what’s outstanding. Overdue items sort to the top.
ddq_answerAnswers the standard external questions from your live architecture rather than from a document.
Composes an answer across memory, the stack map and current audit state.
Responses to the questions that actually get asked. What does your stack consist of. Where does customer data live. Which dependencies carry commercial obligations. What happens if a given vendor disappears. The answer is generated when asked, so it’s right when asked - which is the whole point, because the failure mode of a security questionnaire isn’t that you don’t know, it’s that your written answer is four months stale.
six weeks later, one question.
You’re mid-session in Cursor. You need to add a background job and you’re about to reach for a queue - but something is nagging you, because you have a feeling this came up before.
The decision took twenty minutes to make in April. It took four seconds to recover in June, and it came back with its reasoning and its loose ends attached.
what architecture gives you as you grow.
A record that outlasts your memory of building it. In week seven, when you come back to a project you left in week three, the decisions are still there with their reasoning.
The thing that makes a second person possible. Onboarding stops being a download from your head, and the stack map means nobody has to guess what’s load-bearing.
One architecture across every product, and diligence answers that hold up under questioning because they’re generated from infrastructure rather than written from memory.
Your AI editor supplies decisions and plan cards as you work. Your connected platforms supply the ground truth the stack map is checked against - GitHub for code and dependencies, Supabase and Neon for schema and policies, Vercel and Netlify and Railway for what’s actually deployed where.
One token per platform. Refreshed daily, hourly or every 15 minutes depending on your plan, plus on demand whenever your agent asks.
Architecture tells you what you built. Operations tells you whether it’s up, what it’s costing you and what’s gone wrong overnight.
Architecture tells you what’s in the stack. Audit tells you whether any of it will embarrass you at review.