Memory
Ground the work in verified sources, not temporary scratchpads.
Layer 01 / 07A prompt is just a question. The business is the context.
If a system forces you to re-explain the company every time you ask it to do something, the architecture is broken. Real leverage comes from building a living operational foundation: where brand rules, customer orders, supplier invoices, and current policies exist as durable, inspectable records. When the system already knows how the business works, the work just executes.
The Seven Layers: From Register to Record
Software, store operations, and background intelligence have to share the exact same ground truth.
Staff
Scope each automated role to a bounded desk with a human reviewer.
Layer 02 / 07Routing
Send support questions to support records and invoice anomalies to purchasing.
Layer 03 / 07App
Keep the customer journey clean from menu selection to counter pickup.
Layer 04 / 07Ordering
Anchor every transaction to receipts, payment ledgers, and store fulfillment.
Layer 05 / 07Watch
Catch invoice drift, policy updates, and unresolved tickets before they fester.
Layer 06 / 07Creative
Lock public assets to physical reality so marketing never lies for the product.
Layer 07 / 07Lessons for founders building from scratch and operators improving businesses they run.
Explore WARMScroll to open the stack
WARM gives models a living place to stand.
When a store manager asks what to do about an angry customer or an out-of-stock topping at 9 PM on a Saturday, the answer shouldn't require a scavenger hunt through old Slack threads and stale PDFs.
A visual guide to how the pieces fit.
WARM CANON
Addressable Truth
Store policies, refund rules, and recipes live at permanent, versioned addresses. The system verifies the record's date and approved status before touching it. Recurring questions always start with the current document, not an unverified summary.
WARM Fabric
Versioned Organizational State
A refund-policy change starts a new approved operating version, where matching rules, tool permissions, and role definitions are compiled and reviewed together.
Resident agents
Bounded Seats
A customer support issue and a bulk ingredient invoice require different context. Resident agents are bounded seats with access only to the tools and records their domain needs, returning answers with the source and date so a person can check them.
Warm constellations
Finite Tasks with an Edge
The developing constellation design handles disputed-charge work as a temporary task graph anchored to a snapshot of records. It sets required evidence, steps, and exit conditions before work starts, keeping a complicated case visible, bounded, and ready for review.
The architecture is partially implemented. Residents and routing are implemented. Fabric is a lab compiler, while constellation work is still being developed.
Explore memory and contextTools for the work itself
Software built around the moments where customers, store managers, and corporate operations meet. Clean commerce, auditable loyalty, and operating tools that carry context across every interaction.
Illustrative interface study
Customer and franchisee tools
These tools are for the ordinary things that should not be hard, like placing an order or seeing how a store is doing.
Franchise hubOne place for the work an owner or manager returns to.
A dedicated portal gives store owners and managers a single place for daily sales, labor, P&L metrics, training, and approved brand assets, without sending them through disconnected vendor portals. It is being prepared for rollout.
Loyalty systemStart with signup counts, then give managers something they can coach.
Tracks store enrollments and links staff attribution to signups when attribution is available, turning checkout data into coaching opportunities for store managers. Unattributed signups stay visible.
Native mobile appOne shared commerce engine for menu, orders, loyalty, pickup, and delivery.
The native iOS app is in TestFlight. It uses the same menu, order, and commerce services as the web storefront for store selection, payment, loyalty, pickup, and delivery.
Online orderingA web storefront on the same menu, order, and commerce services.
The native app and web storefront share one menu, order, and commerce engine. The web storefront is still being tested before the public checkout switch.
Memory
Staff
Routing
App
Ordering
Watch
Creative
Illustrative architectureRecurring operating work
Automated chargeback defenseStart a disputed-order review with the evidence already gathered.
The pipeline gathers the payment receipt, order information, and available fulfillment evidence. The store can add its account of what happened. The case is held for the review window, then submitted when policy allows or passed to a manager when the evidence needs review.
Catching Supplier Pricing CreepCompare the same case size before asking why an invoice changed.
It compares what stores paid Sysco for the same item and case size. If prices differ, the manager can open the actual invoice line and ask the supplier about that difference.
Support monitoringKeep an unanswered customer visible to the team.
Runs hourly sweeps on pending support tickets. If an API read fails, the system marks tickets as stale rather than presenting a false empty queue, keeping store teams aware of unanswered customer issues.
The brand breaks when the screen promises something the store can't deliver.
Customers don't differentiate between a digital promo, an ordering app, and the physical box handed across the counter. Brand strategy and operational software are the same discipline: keeping what is promised in sync with what gets made.
TE mark study with fixed geometry and adjustable light and lens.
Move the light and lens. The mark geometry does not move.
A beautiful image is useless if the customer opens the box and gets a different cookie.
Local marketing playbooks
B2B sales execution matched to kitchen capacity.
Step-by-step playbooks for store operators targeting local corporate catering: identifying prospects, setting contact cadences, and deploying approved marketing assets without overpromising what the morning shift can bake.
Digital Twin Photography
Real product authority. Zero generative invention.
Digital Twin Photography starts with studio photographs of real cookies and sodas. AI can adjust only lighting, setting, and focal length, never inventing or changing product features. A person compares the final image with the original, so what customers see matches the cookies and drinks served.
Give AI a job a person can check.
Read the first workflow noteMost businesses begin with orders, store managers, policies, software, and people making calls all day. For a new founder, the first move is simpler: pick one recurring customer problem and write down how it gets handled now.
Keep the policy with the decision and the receipt with the order. That gives the next employee or tool something to work from. Start there, before asking AI to take on a bigger role.
- 01
Choose a repeated task
Pick something that happens often enough to annoy people. For example, gather the receipt, order record, and store response for a customer dispute, then have an operator decide whether the packet is ready.
- 02
Write the handoff
Say what the tool receives, what it should return, and who checks it. If the reviewer can't tell whether the right receipt and policy were used, the handoff isn't clear enough.
- 03
Keep the decision with its source
Policies, receipts, invoices, and operating decisions need a home people can update. Memory should help find them, not replace them.
Memory works when you stop calling everything memory.
For a refund question, the source record is the current refund policy. Long-term memory points to its owner and address. Current context includes the customer's order and question. Retrieval brings the policy and supporting record into view.
SourcesContextRetrieval
Source Records
The ground truth: live receipts, current operating manuals, and supplier contracts.
The current operating policy
Long-Term Memory
Pointers and stable operational facts: who manages store 12, where dispute policies live.
A policy owner and source link
Current Context
The minimal payload assembled for the single question in front of the engine.
The policy and customer request
Retrieval
The auditable trail connecting the output back to the primary record date and author.
A link back to the policy
Illustrative example
How should the store handle this customer request?
A useful answer names the current policy, shows its date, and says what still needs a person to review.
Three practical notes to start with
The first useful AI project is usually smaller than people want it to be. Pick a job where the answer can be checked before it causes trouble.
Start with one checkable jobFounder systems
Begin with a repeated problem and one person who knows what a good result looks like.
A customer disputes an order. That is a job you can name without pretending it covers the whole company. There's a receipt, an order record, sometimes fulfillment proof, and an operator who knows whether the packet is ready.
Write the handoff in plain language: gather the records, show what is missing, and hold the case for review. If the operator can't see what evidence the result used, it isn't ready.
Follow one recent case from start to finish. Where did the receipt come from? Who checks the store's reply? What breaks if an old policy gets used? Those answers give the tool a job worth inspecting.
Memory is not the current questionAI memory
A saved fact can help find an answer. It should not quietly become the answer.
For a disputed order, the receipt and order record are source material. A remembered fact might tell you where the current dispute policy lives or who owns it. Neither one settles the case in front of you.
The model still needs the relevant records, the customer's question, and instructions for uncertainty. Retrieval brings those materials forward and keeps the path back to the source visible to the reviewer.
Try one internal question. List the records that can answer it, then decide which stable facts are worth saving. Give the model only what it needs to answer that question, and keep the source where people can update it.
A date can change the answerOperating records
When a policy changes, an older copy can sound just as convincing unless the date stays attached.
A customer request might match an old policy summary while the current policy says something else. The problem isn't that the old document exists. The problem is treating it as current without checking.
Keep where a record came from and when it was created or updated. A historical note can still be useful, but it should not quietly override the approved policy.
Choose one area where documents have changed. Find the current authority and one older record that could conflict with it. Decide whether the workflow should show the disagreement, prefer the current policy, or send it to a person for review.
Systems built inside the work, not a demo sandbox.
An open record of building durable context, operational software, and brand consistency across an active franchise business.
Connect on LinkedIn