DEV Community: Davide Agosti

Designing a BYOK AI Architecture for a Commercial Framer Template

Davide Agosti — Tue, 01 Sep 2026 16:56:59 +0000

I Built an AI-Enabled Framer Template Without Owning the Buyer’s AI

Most AI-enabled websites hide an architectural decision behind the interface:

Who actually owns the AI?

When I started building CounselForm AI 2.0, a Framer template for modern law firms, I didn't want buyers to depend on an API key that I controlled.

I didn't want to bundle inference into a subscription.

And I definitely didn't want an OpenAI API key sitting somewhere in browser-side configuration.

So I designed the AI layer around a different principle:

The buyer owns the AI infrastructure.

That decision shaped almost everything behind CounselForm AI 2.0.

The product

CounselForm started as a premium Framer template for law firms.

For 2.0, I wanted the website to do more than present pages.

A potential client might arrive knowing they have a commercial problem without knowing:

which practice area is relevant;
which lawyer they should speak to;
whether the firm works in their industry;
which existing insight is relevant;
or even how to describe their problem.

That became the problem behind Ask Lexora.

Instead of replacing the website, Ask Lexora sits on top of its information architecture and provides another way to explore it.

There are two modes.

Guided Discovery

Guided Discovery is deterministic.

It uses structured questions and the firm's trusted knowledge to help visitors navigate relevant expertise, people, industries and insights.

No LLM inference is required.

This was intentional.

Not every interaction needs a model.

AI Mode

AI Mode is optional.

Here the visitor can ask a natural-language question and receive a contextual answer based on the firm's trusted knowledge.

But the architecture introduces an important boundary.

The browser does not talk directly to OpenAI.

And the template seller doesn't provide the OpenAI account.

The simplified flow looks like this:

Visitor
↓
Framer / Ask Lexora
↓
Buyer-owned Cloudflare Companion
↓
Trusted firm context
↓
Buyer-owned OpenAI account
↓
Structured response
↓
Ask Lexora

The buyer supplies and controls the provider credentials.

Why BYOK?

I settled on a Bring Your Own Key / Bring Your Own AI model.

The buyer owns:

the OpenAI account;
the API credentials;
the Cloudflare deployment;
provider usage;
and the resulting inference costs.

The seller doesn't provide a shared API key and doesn't subsidize token usage.

There are a few reasons I prefer this architecture for commercially distributed AI templates.

Credentials don't belong in Framer

A secret placed in client-side JavaScript isn't a secret.

The Cloudflare Companion creates a server-side boundary between the Framer experience and the AI provider.

AI costs stay attributable

If 100 people buy a template, I don't want to become the inference provider for 100 unrelated businesses.

Each buyer pays their own provider costs.

That also means the template doesn't need an artificial seller-managed AI subscription just to recover inference costs.

The buyer isn't locked into my infrastructure

The customer isn't buying access to my OpenAI account.

They're buying the product and architecture.

Their AI remains theirs.

The other problem: what does the AI actually know?

Connecting an LLM wasn't the difficult conceptual part.

Trusting what it says was.

A law firm's website contains specific claims about expertise, people, industries and published insights.

I didn't want Ask Lexora improvising firm-specific facts simply because a language model could generate a plausible answer.

So CounselForm AI 2.0 uses a Knowledge Sync workflow.

Conceptually:

Approved firm content
↓
Knowledge Sync
↓
Trusted knowledge
↓
Deterministic retrieval
↓
Bounded context
↓
LLM
↓
Ask Lexora response

This isn't an autonomous crawler that magically "learns" the buyer's website.

The knowledge is deliberately maintained.

And when the available information isn't sufficient, the safer behavior is to acknowledge that limitation or direct the visitor toward the appropriate contact path rather than inventing an answer.

Not everything needs AI

One of my favorite outcomes from the project is actually Guided Discovery.

It costs nothing in inference.

That matters because AI shouldn't be added simply because a product has an AI feature.

Sometimes structured interaction provides enough value.

So CounselForm can operate perfectly well without an OpenAI account.

AI Mode is an enhancement, not a prerequisite for the website.

The public demo doesn't use OpenAI either

There was one more interesting problem.

How do you publicly demonstrate an AI-enabled commercial template without running every anonymous visitor through a seller-funded API?

The public Ask Lexora preview is therefore deterministic.

It demonstrates the interaction model using curated questions and responses without performing OpenAI inference.

The purchased product can then be configured by the buyer to enable real AI Mode using their own infrastructure.

That gives me a public interactive demo without turning the demo itself into an uncontrolled inference endpoint.

What I ended up building

CounselForm AI 2.0 combines:

Framer;
responsive legal/editorial design;
CMS-powered content;
Ask Lexora;
deterministic Guided Discovery;
optional AI Mode;
Knowledge Sync;
a buyer-owned Cloudflare Companion;
OpenAI BYOK;
buyer setup and troubleshooting documentation;
and a commercially distributable template architecture.

The interesting part for me wasn't simply adding an LLM to a website.

It was figuring out where the AI should stop being my infrastructure and start being the buyer's infrastructure.

That distinction becomes increasingly important when AI functionality moves from prototypes into products that other people actually own.

Try Ask Lexora

CounselForm AI 2.0 is now live, and I've published an interactive preview of the Ask Lexora experience:

Live preview: CounselForm AI 2.0

Framer Marketplace: CounselForm AI 2.0

I'd be particularly interested in hearing how other developers are approaching BYOK, buyer-owned inference and trusted knowledge boundaries in commercially distributed AI products.

Business Context Should Be Infrastructure, Not Prompt Text

Davide Agosti — Tue, 01 Sep 2026 15:39:37 +0000

Business Context Should Be Infrastructure, Not Prompt Text

A lot of AI applications eventually run into the same problem.

The model understands the prompt.

It may have access to tools.

It may retrieve documents.

It may even maintain memory.

But none of those things necessarily mean it has a coherent understanding of the business it is operating within.

That distinction is what led me to start working on Evidensiq, an early-stage open-source specification for portable, evidence-backed business context.

The project is deliberately still at the specification stage. There is no runtime or package to install yet.

Before building one, I want to find out where the model is wrong.

The problem

Business knowledge rarely exists in one place.

A company may have:

product information in a database;
pricing in a CRM;
strategy in documents;
operational constraints in internal notes;
customer information in spreadsheets;
metrics in analytics systems;
policies in PDFs;
and historical information that is no longer valid.

A typical AI application eventually has to turn some combination of those sources into context for a model.

But retrieving text is only part of the problem.

Suppose three sources say:

2025 pricing document → Product A = £100
CRM                   → Product A = £120
Website               → Product A = £110

Which one is true?

More importantly: should the infrastructure silently decide that one of them is true?

I don't think it should.

Evidence is not a fact

One of the core invariants I'm exploring in Evidensiq is:

SOURCE ≠ EVIDENCE
EVIDENCE ≠ FACT
FACT ≠ INFERENCE
INFERENCE ≠ RECOMMENDATION

Or, conceptually:

SOURCE
  ↓
EVIDENCE
  ↓
ASSERTION / FACT
  ↓
INFERENCE
  ↓
RECOMMENDATION

The distinction matters because a recommendation should be traceable backwards.

If an AI system recommends delaying a marketing campaign because production capacity is constrained, I want an application to be able to ask:

Why?

And eventually reach the evidence that supported that conclusion.

Business knowledge is temporal

Another problem is time.

A statement can be false today without having always been false.

The current specification therefore models concepts such as:

validFrom
validUntil
observedAt

The goal is to preserve the distinction between:

FALSE

and:

WAS TRUE

This becomes important surprisingly quickly when AI systems reason over pricing, customers, processes, products, policies or business objectives.

Confidence probably isn't one number

I'm also questioning the common pattern of attaching something like:

confidence: 0.97

to AI-generated conclusions.

What exactly does 0.97 represent?

The current Evidensiq direction separates:

evidenceStrength
sourceReliability
evidenceFreshness
inferenceConfidence
modelConfidence

An application could derive an overall score according to its own policy, but the underlying dimensions remain visible.

Whether this is useful or over-engineered is one of the things I want feedback on.

Data is not instruction

There is also a security boundary that I think context infrastructure needs to make explicit:

DATA ≠ INSTRUCTION

Imagine an ingested business document contains:

Ignore previous instructions and...

That content came from evidence.

It did not suddenly acquire authority over the AI system.

This distinction becomes particularly important when context is assembled automatically from untrusted or externally controlled sources.

What Evidensiq is — and isn't

The intention is not to build another agent framework.

Evidensiq should not own:

agent orchestration;
generic RAG;
vector storage;
workflow execution;
LLM clients;
generic memory;
tool calling;
multi-agent coordination.

Instead, the proposed boundary looks roughly like this:

Application / Agent Runtime
            │
            ▼
        Evidensiq
            │
    Business Context
    Evidence
    Provenance
    Signals
    Inference
    Recommendations
    Validation
            │
            ▼
LLM / Storage / Documents / CRM / other adapters

An OpenAI-based application, a Microsoft Agent Framework application, a LangChain application or a custom system should theoretically be able to consume the same business-context representation.

The portable artifact currently being explored is:

business-context.json

with a provider-neutral JSON Schema.

Before writing the runtime

The obvious temptation at this point would be to start building packages.

I'm deliberately not doing that yet.

The current repository contains the specification, JSON Schema, architecture, terminology, security model and project rationale.

Before locking those abstractions and implementing reference libraries in TypeScript and .NET, I'd like them challenged by other developers.

In particular:

Are SOURCE / EVIDENCE / FACT / INFERENCE / RECOMMENDATION actually useful boundaries?
Is the business model too broad or too restrictive?
Does the temporal model hold up against real systems?
Is multidimensional confidence useful or unnecessary complexity?
Can a context specification like this genuinely remain runtime- and provider-neutral?
Where does this overlap too much with existing context, knowledge-graph or agent infrastructure?
What would prevent you from integrating something like this into a production AI application?

I've opened a technical review discussion here:

https://github.com/davideagosti-dev/evidensiq/discussions/3

The repository is here:

https://github.com/davideagosti-dev/evidensiq

At this stage, disagreement is useful.

I'd rather discover a bad abstraction in a Markdown specification than after publishing APIs around it.

Your Component Fits. But Is It Still Useful?

Davide Agosti — Tue, 01 Sep 2026 14:10:45 +0000

DnDGem

Your Component Fits. But Is It Still Useful?

Responsive interfaces usually answer a geometric question:

Does this component fit in the available space?

But there is another question that is much harder to express:

Is the content still useful at that size?

Those two questions are not always equivalent.

A simple example

Imagine a dashboard panel with these constraints:

{
  minWidth: 120,
  minUsefulWidth: 180
}

At 200px, everything is fine.

The panel fits, and its content has enough room to remain useful.

At 150px, something more interesting happens.

The panel still satisfies its geometric minimum. Nothing necessarily overflows. The browser can render it perfectly well.

But perhaps:

labels become cramped,
a chart loses enough context to become difficult to interpret,
controls remain technically accessible but awkward to use,
or important information becomes harder to understand.

The component still fits.

But its content has started to degrade.

At 100px, the situation changes again: now the component violates its hard minimum width.

These are three different states.

VALID

The component satisfies its geometric constraints and its usefulness thresholds.

DEGRADED

The component still satisfies its hard geometric constraints, but one or more usefulness thresholds are no longer satisfied.

INVALID

A hard geometric constraint has been violated.

That middle state is the interesting one.

Geometry is not usefulness

CSS already gives us extremely powerful mechanisms for responsive design.

Media queries let us respond to viewport conditions.

Container queries let components respond to the dimensions of their containers.

Intrinsic sizing gives the browser sophisticated rules for determining how elements should occupy available space.

None of those technologies are the problem.

The question I'm interested in sits at a different layer:

What should a layout system do when geometry remains valid, but the content inside that geometry is no longer useful?

Consider a data visualization.

A chart might technically render at 160px wide. No overflow. No violated minimum width.

But perhaps its axis labels collide, the legend dominates the plot, or the amount of visible information becomes too small to communicate anything meaningful.

From the browser's perspective, the layout may still be valid.

From the application's perspective, it may have degraded.

Why model DEGRADED explicitly?

A binary model gives us:

VALID
INVALID

But adaptive interfaces often have a meaningful region between those states:

VALID
   ↓
DEGRADED
   ↓
INVALID

Making that middle state explicit gives the application another piece of information to reason about.

For example, a layout engine could decide to:

reduce lower-priority content,
switch to a more compact representation,
move something elsewhere,
reflow the surrounding layout,
or simply expose the degraded state and let the application decide.

The important part isn't prescribing one universal response.

It's recognizing that "fits" and "remains useful" describe different constraints.

Exploring the idea with DnDGem

This distinction is what I've been exploring in DnDGem, an open-source adaptive layout engine.

DnDGem separates hard geometric constraints from content-usefulness constraints.

A simplified example looks like this:

{
  minWidth: 120,
  minUsefulWidth: 180
}

minWidth represents a hard geometric boundary.

minUsefulWidth represents the point below which the content is considered degraded, even though the component may still geometrically fit.

The resulting state becomes information that an adaptive layout system can use when evaluating layout decisions.

The goal isn't to replace CSS, media queries, container queries, or intrinsic sizing.

It's to explore an application-level question those mechanisms don't necessarily answer on their own:

When should an interface react to loss of usefulness rather than only loss of geometric fit?

Try the idea

I've written a more detailed explanation of the model, including the reasoning behind VALID, DEGRADED, and INVALID:

https://dndgem.dev/articles/geometrically-fits-content-remains-useful/

There's also an interactive playground:

https://playground.dndgem.dev/

But I'm particularly interested in how other frontend engineers approach this problem.

When a component technically fits but its content no longer works well, how do you represent that boundary in your applications today?