The DNAForge Calendar Stack

Founder calendars are not just availability grids. They are operational state: who is entering the company orbit, what needs preparation, which follow-ups are open, and which decisions should be remembered before the next conversation.

That is why we do not treat scheduling as a closed booking widget. DNAForge uses a small stack where the calendar, booking layer, agents, and memory layer each have a clear job.

Google Calendar is the source of truth. If a meeting is real, it lives there. Agents can create, move, and cancel calendar events directly when the workflow requires it.

Cal.com is the programmable booking layer. It gives us public and private links for solo founder calls, joint DNAForge meetings, and onboarding. It handles availability, event types, buffers, booking fields, host routing, and calendar writes.

Agents operate around the meeting. They prepare context, make reminders, reschedule when needed, and turn outcomes into follow-up work instead of treating scheduling as a human-only UI task.

The brain is the durable memory layer: Markdown in Git, indexed through gbrain/Supabase. It stores what a calendar should not carry: who the person is, how we know them, what happened last time, what follow-up is open, and what should be remembered before the next conversation.

A DNAForge onboarding call can start from a Cal.com link. The booking lands on Google Calendar, the event becomes a real scheduling object, and an agent can prepare from people, company, project, and prior-meeting notes before the call happens.

After the call, the same system can update the meeting record, create reminders, capture follow-up tasks, and preserve the relevant context for the next interaction. The useful unit is not the booking itself. It is the loop around the booking.

A closed scheduling widget can collect a time. Scheduling infrastructure exposes enough surface area for agents to compose tools: read availability, route hosts, create events, move events, cancel events, update event types, and connect the resulting meeting to memory.

Cal.com fits that shape because it is not only a hosted page for choosing slots. It is a programmable booking layer, with APIs around event types and calendar routing, and with a self-hosting path if deeper ownership or control becomes necessary.

We are not trying to make Google Calendar carry every detail. The calendar stays the calendar. Cal.com stays the booking surface. The brain stores memory. Agents connect the pieces.

Useful AI scheduling is not a chatbot that books meetings. It is a small operating system where scheduling, memory, follow-up, and recordkeeping are connected.