How to Build Your First AI Product: A Keynote at the Futures Summit

A mainstage keynote at the California Community Colleges' Futures Summit 2026, September 9, Santa Clara.

By N2N Services · September 9, 2026

On September 9 at the Santa Clara Convention Center, N2N Services Founder & CEO Kiran Kodithala joined a lineup of national education, policy, and technology leaders on the mainstage of the California Community Colleges' Futures Summit 2026 — a two-day national gathering hosted by the California Community Colleges Digital Center for Innovation, Transformation and Equity, in partnership with the CCC Chancellor's Office and the Foothill–De Anza Community College District. Nearly 1,000 educators, technologists, policy leaders, and students gathered under the summit's 2026 theme, Human Skills in an Autonomous World.

Kiran's keynote had a deliberately simple title: "How to build your first AI product." The premise: at this moment in the industry, the question is no longer whether faculty, staff, students, and administrators inside a college — or founders and operators outside one — should build AI products. It's how a person who has never shipped software before actually gets from a spark to a working, governed, real product, without disappearing into a two-year integration project or a nine-figure re-platforming bet.

Watch the full keynote

Kiran Kodithala, Founder & CEO, N2N Services · "How to build your first AI product" · CCC Futures Summit 2026 · September 9, 2026 · Santa Clara Convention Center · 7:34. The presentation deck plays alongside the talk on the right; English captions available via the player's CC button.

Try Meridian (Early Access) No sign-in needed — build a governed tenant in about 30 seconds.

The three moments in the talk

The forgotten fact. Kiran opened on the observation the rest of the industry has been busy forgetting: every enterprise software category we treat as immovable — the SIS, the ERP, the CRM, the LMS — was, at one point, someone's first product. Somebody once built the first student information system. Somebody once built the first financial-aid packaging engine. The reason we think those categories are settled is that the incumbents shipped decades ago and the migration cost of everything that came after has kept them there. That fact, Kiran argued, is exactly what agent-native platforms are about to reset.

5,000,000 lines of code. The talk walked the audience through what has changed, concretely, in the last twenty-four months. Building working, governed enterprise software — with tenant isolation, an audit log on every write, versioned APIs, and a real UX — has stopped being a story about hiring a large engineering team and shipping a two-year roadmap. Working from that same premise, N2N built and ships Meridian: an agent-native platform that lets a person describe an enterprise application in one sentence and get back a working, governed, multi-tenant tenant on its own database — objects, roles, records, APIs, and automations included — in the time it takes to pour a cup of coffee. Five million lines of code, provisioned live from a prompt, running on hardware you can point at.

The invitation. Kiran closed by turning the keynote into a working session for the room — an offer to any Futures Summit attendee to walk over to the N2N booth the next day (Friday, September 11, Convention Center, Room SGS/04) and build their first AI product side-by-side with the team. Not a demo the attendees watched — a real, governed application they walked away owning.

What happened the next day

The workshop that ran on Friday, September 11, from the N2N booth was the second half of the keynote's argument. Ninety minutes. One shared, pre-provisioned dev tenant (workshop-demo-2026-09-11). Twelve builds, in order, each attendee driving the workflow from their own laptop against the live dev.lightleap.ai/meridian runtime. Every write landed in the shared tenant's own audit log, under the acting attendee's user record, in real time.

The build sequence:

Prompt → whole tenant. One sentence to the templates generator. A working, governed multi-tenant application — objects, roles, RBAC, audit, page builders, reports, APIs — proposed in a plan card the attendee reviewed before anything was written.
Build the first tenant. Guest funnel → identity captured first (email + workspace slug before the prompt) → owner sign-in. Real magic-link email, real password. Nothing simulated.
Create + provision users. Teammates added without a support ticket. Roles picked from the tenant's live config; every invite carried an audit row (tenant.user.added) under the tenant.
Extend the tenant via Omnify. "Add an Onboarding module — a New Hire object, a Task object linked to each new hire." NDJSON progress stream, plan card, inline confirm, applied through the same audited write path the root generator uses. No new codepath. No consultant.
Edit pages inline. Rename a tab. Add a records-table block. Add a priority select field. All without leaving the live page — routine ops save directly with an audited Undo; high-stakes ops (delete a tab, remove a block) pause on an inline confirm card.
Create reports. Visual Report Builder → runner → assignment → CSV export. One ReportDef, running through the same /api/records enforcement as the rest of the platform. Row-scope, field-RBAC, and FERPA masking all honored end-to-end.
Expose APIs. Any governed object → a versioned REST API. Issue an mk_live_* key (the plaintext shows once, then only the hash persists). The interactive Scalar-rendered OpenAPI 3.1 docs live-test against the tenant.
Modify roles. Mint a "Hiring Manager" role. Give it a dashboard. Restrict the notes field to read-only. The change takes effect on the next request. No cache invalidation.
Create agents. Author a plain-language Data Agent. Watch the streamed proposal: a read-only tool catalog derived from the tenant's metadata, projected through the acting role's field-RBAC. Every step in the run — plan, per-step observation, filter narrowing — visible in the trace panel. Every action audited.
Build integrations. Same day. Wire an SES email connection and a generic-REST connection to a mock external tenant. Every secret KMS-encrypted at rest, bound to the tenant slug. Every probe, invocation, rotation, and delete audited.
Omnify — one conversational surface. Four prompts, four honestly-routed destinations: a data-model change applied in place; a report request routed to the Report Builder; an automation routed to the Automation Builder; an integration ask routed to Integrations. Omnify never fabricates an action.
Data Studio. Natural language and raw SQL over the tenant's own database. Every read audited. Every write previewed, confirmed, and reversible.

The evidence strip — six pillars, verified

Every one of the twelve builds sits inside the same six architectural invariants — the ones the platform's Quantum Mandate commits to on paper and the workshop demonstrated in flesh:

Multi-tenant by default. Database-per-tenant is the primary isolation; row-level security is belt-and-braces. The workshop tenant had its own physical DB, teardown-able with one operator command.
Audited. Every write appended a row to core.audit_logs in the same transaction, mirrored best-effort to the cross-tenant control-plane. The presenter closed the workshop by pulling the master log and scrolling past every attendee's build.
AI-refusable. State-based honesty guards, always-confirm inline cards (never a browser confirm(), never a modal), and a fabricated-action guard that intercepts completion claims when no write actually ran.
Regulated-safe. PII / FERPA / GLBA fields excluded from embeddings, masked in audit-log redaction, KMS-encrypted at rest, and never sent to a model that trains on them.
Reversible. Every release is a flag flip or a git revert away from before. Integration Studio itself is a single env var (MERIDIAN_INTEGRATION_STUDIO) — unset, and the tab disappears, the routes 404, and the notify surface falls through byte-identically to the pre-Studio path.
Attestation-congruent. Every "yes" on HECVAT, SOC 2, TX-RAMP, WCAG 2.2 AA, and VPAT is delivered by the runtime on every release — not asserted in marketing. This is Article IX of the Mandate, and the workshop was structured to make that congruence visible on stage.

What we chose not to claim

The workshop's Integration Studio segment (build #10) shipped a real, live feature — the ADR-0054 Phase-1a release with email and generic_rest adapters. It did not ship what marketing pages in this category usually claim it ships. The presenter said so on-stage; the deck said so on-slide; and it belongs in this recap for the same reason:

No Salesforce / Workday migrations today. Those are Phase 1b+, on the roadmap, blocked on real adapter work in Helios.
No Helios pipeline visibility today. Deferred to Phase 1b; the source doesn't match the deployed surface yet.
No inbound webhook receivers. Documented follow-up. POST /api/connections/[id]/webhook is not shipped.
No MCP server (Model Context Protocol). The ADR is written; the code isn't. Naming a plan is not the same thing as shipping it.

The workshop's ADR trail, the release notes, and the 9-of-9 green CDP smoke evidence are all in the release doc — no self-marking, no illustrative figures. Every claim above is grounded in one of AGENTS.md, CHANGELOG.md, the Sept 11 ADR-0054 amendment, or the workshop's own audit log.

From the room

Four screens attendees drove during the workshop:

Meridian templates generator — the one-prompt front door: 'Describe any enterprise workflow. We build the software.' with a live plan card on the right.

Meridian Report Builder — click-to-drag column composer with base-object picker, joins panel, and live-preview through the audited engine.

Meridian API Docs — Scalar renders the tenant's live OpenAPI 3.1 spec; attendees mint an mk_live_* key, paste it into the auth header, and hit the same governed endpoint their app runs on.

Meridian Data Agents — plain-language authoring for read-only data agents; every step of every run visible in the trace panel; every read audited under the tenant.

Why this session, and why now

The 2026 Futures Summit is one of the largest national gatherings of higher-education leaders anywhere in the country. Its 2026 program deliberately centers not just the technology, but the human skills — creativity, judgment, collaboration, leadership — that make an institution's use of that technology defensible. Kiran's keynote sits inside that frame on purpose: the point is not that AI can build software faster; it's that when it does, the humans in the room finally get to decide what to build. The choice moves back to the campus, the classroom, and the student services office where it belongs.

N2N Services is grateful to the California Community Colleges Digital Center for Innovation, Transformation and Equity, to the CCC Chancellor's Office, and to the Foothill–De Anza Community College District for the invitation, and to every attendee who came up to the stage after the session to say "I want to build the thing I've been carrying around in my head for years." That's the whole point.

Also see

The Birth of Meridian — the founder's-note companion piece from August 31, on the ten weeks that produced the platform Kiran demonstrated at the Summit.
Meridian — the platform — the full product page, including the walkthrough from prompt to running tenant.
The Quantum Mandate — the twelve-article platform doctrine every claim on this page sits inside of. Article IX is the one the workshop was structured to make visible.
Try Meridian (Early Access) — build your first AI product now. No sign-in needed; you get a governed tenant on its own database in about 30 seconds.