Forge is now a platform: build AI-powered products without touching an LLM API

Here is the question we kept hearing from the teams who had outgrown one-shot AI integrations: what do you do when you need to ship an AI-native product to your own users, not just use AI internally?

You need isolated environments per customer. You need your end-users to get a session without creating a Forge account. You need a pre-configured AI persona ready the moment someone signs up. You need voice to work. You need to know exactly which tenant drove which usage, down to the request. You need all of this to compose cleanly, because you’re shipping it yourself, not running it as an experiment.

This week, Forge shipped all of it.

What a portal is

A portal is a product built on top of Forge. It gets its own registry entry, its own sub-organisation hierarchy, and its own usage attribution chain. When a portal provisions a new customer, it creates an isolated org for that customer — a walled environment with its own agents, its own memory, and its own role structure. The portal’s parent org can observe and govern the whole hierarchy; the customer orgs are completely isolated from each other.

This is the multi-tenant model that every SaaS team eventually needs to build. Forge now ships it as infrastructure.

The provisioning journey

Walk through what happens when a new expert joins a portal product:

1. The portal registers with Forge — a single API call creates the portal record and establishes the parent-org relationship.
2. A new expert signs up — the portal’s backend calls Forge’s tenant provisioning API. An isolated org is created for that expert. An AI persona — configured for that product’s context, pre-loaded with the right skills and personality — is seeded automatically into the new org.
3. A student (or end-user) arrives — the portal issues a short-lived guest token scoped to that expert’s org and one specific agent. The student gets a fully functional AI session with no Forge account, no login flow, no credentials to manage. The token expires in 60 minutes.
4. Voice works — the same guest token can be used to proxy a voice session. The student can speak; the AI responds. No additional auth handshake required.
5. Usage is attributed — every request flowing through a portal carries the portal ID and the full org-chain. Billing, rate-limiting, and observability all work at the right level. The portal operator sees their aggregate; each tenant sees only their own.

The standards underneath this are production-grade: RFC 8693 token exchange for cross-domain delegated auth, RS256-signed session tokens with a JWKS endpoint for verification. These aren’t bespoke — they’re the patterns large-scale auth systems use, applied to the agent-session layer.

Memory that follows users everywhere

Running in parallel with the portal work: Forge’s org memory now operates across every surface the platform supports.

Org memory — the vector-backed knowledge store that agents can write to and search — is no longer limited to chat and workflow runs. It now works from Telegram too. An operator can send a message in Telegram and have that fact land in the org’s shared memory, accessible to every agent in every subsequent session, on any surface.

The practical implication: context doesn’t reset between how you talk to Forge. A fact remembered through a Telegram exchange is available when a workflow agent needs it the next morning. A detail written during a workflow run is there when you open a chat session. The memory is the org’s, not the surface’s.

Auto-promotion has also shipped: agents in long conversations can flag key insights for promotion into org memory — not as a dump of the whole conversation, but as a selective, deduplicated write. A per-run cap and a durability gate prevent noise from compounding over time.

Vision and the Ctrl+V moment

One more thing that quietly shipped this week: paste a screenshot directly into the Forge chat with Ctrl+V.

This is one of those features that sounds trivial and turns out to require real coordination. Forge talks to multiple LLM providers — OpenAI, Anthropic, and others — each with different image input schemas. The platform now translates image formats transparently, auto-labels which providers are vision-capable at startup, and routes image requests to a matching provider without the user needing to think about it.

The workflow: hit Ctrl+V in the chat composer, the screenshot appears as an attachment chip, send. The AI sees it. No save-to-disk, no upload dialog, no worrying about which model you’re talking to.

What this means for builders

The portal infrastructure removes the four hardest things to build correctly in an AI-native multi-tenant product:

• Identity and isolation — per-tenant orgs are walled by construction, not by convention.
• End-user sessions — scoped guest tokens mean your users never touch Forge directly.
• AI persona at signup — the right agent is ready in the new org before the user sees the UI.
• Usage attribution — billing and observability work at every level of the hierarchy.

Anthropic’s engineering team put it well: the most successful implementations build with simple, composable patterns rather than complex frameworks. The portal primitives are exactly that — a small set of well-defined APIs that compose into a complete product infrastructure.

You don’t need to build this yourself. The infrastructure is there. The question is what you’ll build on top of it.

Try Forge — or reach out at [email protected] if you want to talk through what a portal deployment would look like for your product.