13 capabilities. 10 shipped. 3 planned. No blur between them.
Every AILK capability is scored Installed or Platform Service — never folded into one undifferentiated feature list.
This is the roster we hold ourselves to before we sell it to you. We don't invent ship dates for what isn't built. If a capability isn't shipped, this page says so — not your account manager, three months into the engagement.
Why we publish what isn't built yet
Hiding the roadmap costs more trust than showing it. A buyer evaluating a pre-launch foundation can't verify a promise — only a label. So every AILK capability carries one of two: Installed, meaning it's in the repo and running in production today, or Platform Service, meaning it's scoped and scheduled but not built. Most vendors describe unshipped features in the present tense and let the buyer discover the gap later. We built the opposite habit on purpose. The `ailk audit` CLI that scores a site's AEO structure runs today. The Enterprise multi-tenant entitlement that lets a firm manage a portfolio of client sites from one dashboard does not. We say so, on this page, without softening the gap with an invented date. The bet: a serious evaluator — an agency standardizing its stack, a developer deciding what to build on — discounts an unlabeled roadmap and rewards a labeled one. If we're wrong about that, the roster stays honest regardless.
What's shipped, what's planned
10
Installed — shipped, running in production
3
Platform Services — planned, not yet built
13
Total capabilities tracked publicly, no exceptions
What ships today: the Installed capabilities
Ten capabilities, in the repo, running on our own sites right now.
Typed schema registry
Sixty page types, each with its own Zod validation and JSON-LD builder generated straight from frontmatter. Ship a page and the schema markup ships with it — no separate plugin, no manual JSON-LD authoring.
FAQ, glossary, and entity markup
Organization, Person, and LocalBusiness identity markup, plus FAQ and glossary schema, are native to the page types. The structure a model needs to attribute a page to a brand is built in before you write a word of content.
Peer-surfaces architecture
Three apps in one repo — `apps/web` for humans, `apps/mcp` for agents, `apps/api` for programmatic callers. CI checks the parity between all three on every commit; a mismatch fails the build instead of shipping quietly.
First-class MCP server
Agents call AILK the same way a human browses it. The MCP server exposes the site's capabilities as typed tools, tested against the same parity suite as the web UI on every commit.
`ailk audit` CLI
Run it pre-launch and again in CI on every pull request. It flags the missing schema, the ambiguous entity, and the page with no JSON-LD while there's still time to fix it — the alternative is hearing about it from a client.
Apache 2.0 license
The entire OSS layer is Apache 2.0. No source-available carve-out, no license that flips once you start making money. Paid tiers add capability on top; what's already in the repo stays there.
`create-ailk` scaffolder
One command generates the three-peer-app skeleton — web, MCP, API — wired and ready to deploy. What used to take a senior developer a setup sprint now takes one terminal command.
The `.claude/` agent-skill bundle
Eight named skills — `extract-design-from-reference`, `suggest-site-pages`, `scaffold-page`, `add-schema`, `audit-site`, `scaffold-auth`, `scaffold-commerce`, `provision-config` — ship with the repo so an agent can carry setup and iteration work end to end.
JSON-LD emission from frontmatter
Structured data compiles straight from the MDX frontmatter you already write. There's no separate config file to keep in sync — the content and the markup describing it live in the same place.
Working Theory integration surface
AILK stands alone for developers and agencies. For customers who also run Working Theory Platform, the two publish into the same substrate with the deepest integration available — better together, never required.
What's coming: the Platform Services roster
Three capabilities, scoped and scheduled, not yet in the repo.
Multi-tenant entitlement (Enterprise)
White-label branding, per-seat licensing, and cross-site rollup reporting — built for firms running a portfolio of client sites rather than one at a time, gated as a planned Enterprise entitlement rather than a separate tier. It's scoped, not shipped, and we're saying so plainly rather than dressing it up as available.
Fleet management dashboard
One screen showing every client deployment, every AEO score, and every pending update — instead of the twenty separate logins a multi-site agency juggles today. This depends on the Enterprise multi-tenant entitlement's per-seat model existing first, so it ships after that entitlement, not alongside it. Neither has a locked date yet.
Pro lead-routing pipeline
The system that routes a Pro trial signup straight into a sales conversation, without someone triaging the inbox by hand. We'll build it once trial volume justifies automating the handoff. Until then, every signup reaches a person — slower, but it's where the team's attention actually goes, rather than a script standing in for the real thing.
Why isn't the multi-tenant entitlement live yet?
Why isn't the multi-tenant entitlement live yet?
Because building it before agencies told us what they needed would mean guessing at per-seat pricing, white-label scope, and rollup reporting — and shipping a v1 that doesn't match how firms actually run a portfolio of sites. We're gathering that input before it gets built, not after — reach out through the pricing page if fleet management is a requirement for your firm. Everyone else gets it built once, correctly, instead of rebuilt twice.
We run on the same roster we're showing you
Sam Henry, Working Theory, and SalesSmyth all publish on AILK today, on the Installed capabilities listed above — not a version with extra features switched on for the team that built it. The schema registry and the peer-surfaces architecture exist in their current shape because we hit the problems those capabilities solve first, on our own sites, before shipping them to anyone else. Call it the origin of the design rather than a testimonial about it. If the `ailk audit` CLI ever produced a false pass, we'd be the first to notice — we run it against our own pages, in our own CI, before anyone outside the team does.
Capability roster — common questions
What's the difference between the OSS layer and the paid tiers?
The OSS layer under Apache 2.0 is structurally complete — schema registry, peer surfaces, the audit CLI, and scaffolding all ship free. Pro and Pro Plus add capability on top of that foundation. Neither tier gates access to what's already in the repo.
Is the `ailk audit` CLI part of the Installed set or a Platform Service?
Installed. It ships in the OSS layer today, runs pre-launch and in CI on every pull request, and scores a site's AEO structure for free. It's one of the ten capabilities running in production right now.
Will Installed capabilities ever move backward into Platform Services?
No. Once a capability ships in the OSS layer under Apache 2.0, it stays. Reversing that would break the license promise the whole roster depends on — the same promise that gives the Installed label its meaning.
Start on what's already shipped
Ten capabilities are running in production today — clone the OSS foundation and use them now, or book a Launch Service call and we deploy them for you. Managing a portfolio of client sites instead? See the Enterprise entitlement on the pricing page.