AI-native, defined honestly - what it should mean and how Autonnel implements it

“AI-native” has become the kind of phrase that product marketers reach for before they’ve finished their coffee. It sits in the same drawer as “platform,” “ecosystem,” and “next-generation” - words that once meant something and got sanded smooth by overuse. I want to try to rescue it, or at least define what I think it should mean, and then be honest about whether Autonnel actually lives up to that definition.

My working definition: AI-native is a claim about where AI sits in the default workflow, not about how many AI features a product has. A product with twelve AI features, all optional and all off by default, is not AI-native. A product where the first authoring action is a prompt - and everything else flows from that - might be. The distinction matters because it changes what you optimize for, what your users’ mental models are, and what falls apart when the model is wrong.

AI-as-feature vs. AI-as-default-authoring-surface

Here is the split that I think is worth naming clearly.

AI-as-feature looks like this: you open a page builder, you drag components onto a canvas, you type copy into text fields, and somewhere in the toolbar there’s a “Suggest with AI” button. The model gives you some copy options. You pick one. That’s it. The page builder is still the bottleneck. The AI shortened one step inside a workflow that was designed without it. Nothing is structurally different.

AI-as-default-authoring-surface looks like this: you open a funnel creation flow, you write a prompt describing what you want, and the model emits the page. Not a blob of HTML. Not some loosely structured suggestion you have to clean up. Structured component props - the same data format that the existing rendering system already understands - that flow directly into the render pipeline. Refinement happens on the output through the same drag-and-drop editor you’d use anyway, but the starting point is AI-generated rather than a blank canvas or a template.

The difference in bottleneck is the point. With AI-as-feature, every page still starts with a human moving components around, and the AI marginally speeds up copy. With AI-as-surface, the prompt is what the human authors, and the rest is refinement. The human’s cognitive load shifts from “how do I construct this layout” to “how do I describe what I want.” That’s a real shift, and it’s worth being precise about whether a product has actually made it.

There’s a failure mode in AI-as-surface that AI-as-feature doesn’t have: the model has to be right enough. If it outputs garbage, you’re not slightly slower - you’re starting over. That’s a real constraint, and I’ll come back to it in the honest-limits section. But it’s a constraint of a different class than “the AI suggest-copy button gave me copy I didn’t like.” It changes how you design the feedback loop, the error handling, and the user expectation-setting.

There’s also a subtler implication. When the authoring surface is a prompt, the barrier to starting is lower and the barrier to getting something correct is higher. A non-designer can describe a funnel. They cannot necessarily debug why the model produced the wrong layout. That tradeoff is real and you shouldn’t hide it behind enthusiasm.

Autonnel’s four AI surfaces

Autonnel has four places where AI is wired into the product. Three are live. One is infrastructure without the LLM layer on top yet.

Page generation. This is the clearest AI-as-surface claim. When you create a new page in Autonnel, you’re given three paths: manual drag-and-drop via the Puck editor, template selection, or AI generation. In the AI path, you describe the funnel you want, and the orchestration layer sends the prompt to the configured LLM provider. The LLM outputs structured Puck component props - not HTML strings, not markdown, but the same JSON config format that the Puck editor reads and renders natively. Those props go through the same render pipeline as anything you’d build by hand.

The discipline that makes this work: the model must output schema-valid props or the page will not compile. There’s no lenient mode where it kind of works. Either the output matches the component schema or generation fails and has to retry. That constraint keeps the AI path from drifting into a special rendering branch that gradually diverges from the rest of the system.

Conversion analysis cron. This runs on a configurable cadence, defaulting to two hours, with a floor of 30 minutes. The cron pulls recent funnel data - page visits, conversion events, abandonment points - constructs a prompt with that context, runs it through the configured LLM, and routes the findings out through the notification layer. That layer handles email, Slack, and webhooks. Webhooks are HMAC-signed so you can verify the source, and notification logs are retained for a short window before being cleaned up.

The point of this surface is ambient analysis. You don’t have to go ask the system what’s happening with your funnel - it tells you, on a schedule you control. Whether what it tells you is useful is a separate question (see: honest limits), but the structural feature is that the LLM is running in the background watching your funnel rather than sitting behind a button you have to remember to click.

Behavior analysis. This interprets the user-interaction event stream. Autonnel collects events like page views, input changes, and form-validation failures, then turns that stream into a prompt and runs it through the LLM to surface friction patterns. Output flows through the same notification layer as conversion analysis. The idea is that conversion numbers tell you what happened; behavior analysis is supposed to tell you where things broke down before conversion - which field caused drop-off, which step had validation failures, where users stopped typing.

I’ll be honest: this is the surface I’m least confident about. The event schema is solid and the pipeline runs. Whether the model’s interpretation of those events is reliably useful is something I’m still evaluating. It’s easy for a model to say “users seem to struggle with the email field” when the data shows a validation-failure spike; it’s harder to trust that analysis when the signal is noisier.

A/B variant suggestion. The infrastructure exists. The data model is in place and the A/B testing machinery runs. What doesn’t exist yet is the LLM layer that looks at current variant performance and proposes the next experiment. That’s the logical next step - closing the loop between “we have performance data on variants” and “we want the model to suggest what to try next.” I’m not announcing a timeline because I’ve learned to stop doing that. But it’s a natural extension and the data model is ready for it.

Concrete implementation walkthrough

The provider abstraction is worth describing because it’s where the “AI-native” claim gets operationalized rather than just stated.

All four AI surfaces call a shared invocation helper rather than hitting a provider directly. That helper reads LLM configuration - base URL, API key, model - from a per-tenant config store. Each tenant in the SaaS deployment can configure their own provider. For OSS single-tenant deployments, the same keys fall back to environment variables transparently. There’s a Settings → LLM admin UI where you set these values; you don’t need to touch environment files.

The practical result is that tenants can point to different models. A cost-conscious deployment can pick a smaller, cheaper model. One that wants maximum generation quality picks a flagship one. And because the base URL is configurable, any OpenAI-compatible third-party provider - a local Ollama instance, a company-internal proxy, a budget API alternative - works without code changes.

When no LLM is configured, the helper throws a typed error. The UI checks for this and hides the AI generation option from the page-creation flow. The conversion-analysis and behavior-analysis crons check for it and skip silently. Every non-AI feature keeps working. Graceful degradation was a design requirement, not an afterthought, because I didn’t want OSS users who don’t want to configure an LLM to see a broken product.

Honest limits

Four things I won’t paper over.

LLM cost is real. Every conversion-analysis run costs tokens. The default cadence is two hours, which is reasonable for most funnels. The 30-minute floor is configurable, but if you set it there without understanding your token costs, you’ll have a surprise at the end of the month. This is especially true for behavior analysis running against high-traffic funnels where the event volume is large. I’ve tried to document this in the admin UI copy, but documentation only helps people who read it.

Hallucinated component props. The model occasionally emits props that don’t match the component schema. The validator catches it, page generation retries, and usually the retry succeeds. But not always on the first attempt, and retries cost tokens and add latency. I’ve tuned the prompt to reduce this, but I haven’t eliminated it, and I’m skeptical anyone has completely solved it. The schema-validation discipline is the right answer, but it comes with a cost.

No autonomous deploys. The model proposes. A human accepts. There is no path in the current system where the LLM modifies a live funnel without a human reviewing the change. That’s intentional. I don’t trust LLMs enough to give them write access to production funnels without a human in the loop, and I don’t think you should trust any product that does. The value is in shortening the time from “idea” to “something to review,” not in removing review entirely.

Evaluation is hard. I won’t claim “AI-generated funnels convert X% better.” That would require controlled experiments I haven’t run, attribution modeling that’s always messy, and an honesty about confounds that most case studies skip. What I can say is that AI-generated funnels start somewhere reasonable rather than blank, and that the conversion lift - if there is one - comes from iteration. Generation is how you get a starting point faster. The work after that is the same work it’s always been.

The thesis restated

AI-native means AI is the default authoring workflow, not an optional enhancement layer on top of a workflow designed without it. That’s a narrower definition than most vendors use, which means a lot of products calling themselves AI-native are, by this definition, not. That’s fine - the honest category for those is “AI-enhanced,” which is a real and useful thing. I just think the distinction matters because it sets different expectations for users, drives different technical decisions, and produces different products.

Autonnel is AI-native by this definition in its page-creation flow, and AI-ambient in its analysis layer. Whether that’s the right balance is a question I’d genuinely like to hear arguments about. The term will probably get diluted further regardless - that’s what happens to useful terms. But I’d rather state the definition clearly and argue for it than avoid the conversation.

If you think this is wrong, or that there’s a better way to draw the line, open an issue.

The follow-up on what happens when you let an agent do more than write copy is funnels for agents, and the storage decision that makes it safe is in why pages are component trees. Both capabilities are in the free self-hosted edition.

• github.com/autonnel/autonnel · Issues and feedback welcome.