Your customers describe what they want. Forge ships it.

Your customers ask for features you haven't built. Forge writes, validates, and ships them into your product — scoped per customer, sandboxed per namespace, and only able to touch what you've declared. You bring the trigger. We bring the agent.

Request access How it works

acme.com — your product

Your customer types what they want

Add an extension

alert me when MRR drops more than 10% in a week

Globex Co. · build session Build

Forge ships a working extension

MRR drop watcher

Active

Alerts ops when MRR drops more than 10% week-over-week.

trigger weekly cron · mon 9am

delivers Slack alert to #revenue

scope Globex Co. only

Also running for Globex

VIP auto-tagging

Tags accounts as VIP when lifetime spend crosses $50K

event · customer.update Updates CRM tag

Custom vendor intake

Adds your industry's compliance fields to the new-vendor page

renders inline · on demand Embedded form

Board metrics PDF

Builds Monday's board deck from last week's KPIs

weekly cron · mon 8am Email + Drive

Illustrative. Forge sits inside your product; your customer sees your branding, not ours.

Agent harness

Codegen, validate, retry, ship

Forge interprets your customer's intent, writes the extension against your tools, type-checks it, validates every trigger and tool binding against your registry, and retries on error. It's the loop most platforms try to build themselves and stall on.

Capability surface

Your tools, auto-discovered

Point Forge at your MCP, OpenAPI, or GraphQL endpoint. Forge introspects it and exposes only those operations to the build-time agent. Extensions can never reach a tool you didn't declare — sandbox-safe by construction.

Sandboxed runtime

One namespace per extension, per customer

Shipped extensions run in isolated namespaces with scoped secrets, state, and triggers. No shared globals, no cross-customer reads. You stay in control of what each extension can touch.

Who owns what

You keep the surface. We do the work no one wants to maintain.

You bring

→ The trigger — chat box, button, ticket pattern, scheduled job.
→ The model provider — BYO key or pay through us.
→ The product surface where extensions live.

Forge ships

→ The build-time agent — codegen, validation, retry-with-error-feedback.
→ The capability registry — sources auto-discovered from your MCP / OpenAPI / GraphQL.
→ The event-type catalog and event delivery into runtime extensions.
→ The runtime, lifecycle API, and management surface.

Built around isolation

Nothing crosses customer lines.

Every architectural choice starts from one principle: an extension built for one of your customers cannot reach anything outside its sandbox or anything you didn't declare.

How isolation works →

→ One sandboxed namespace per extension. Scoped secrets, scoped state, no cross-customer reads.
→ Capabilities are validated at build time; extensions can't call a tool you didn't expose.
→ HMAC-signed dispatch with per-subject headers. Forge stores no per-customer credentials.
→ Every extension lands in pending_approval. Nothing runs until your customer approves.

Forge doesn't change what an agent can author. It changes who can build the agent in the first place.

Ship the long tail without growing the roadmap.

Pilots are open with a small group of vertical SaaS partners.

Request access