Brix
AI-built extensions your customers create inside your app.
Add a place in your product where customers describe the integration, rule or automation they need. Brix generates it from their API documentation, tests it and runs it in isolation, with credentials they control.
Your customerWhen a deal over $10,000 closes, post it to our #wins channel with the owner's name.
- Plans from the Slack API docs
- Writes and reviews the code
- Asks for the Slack token securely
- Tests, then publishes v1
What customers build with Brix
Tools for your AI agent
Your agent gains customer-specific tools, such as looking up a quote in their ERP or searching their CRM, without you writing a connector for each one.
Rules
Decisions your app asks at runtime, like whether to allow an action or which route to take, written to each customer's policy.
Actions
Transform or forward data when something happens in your app, using the customer's own systems and accounts.
One SDK on your backend
Your app keeps its own sign-in, tenants and UI. Your backend uses the SDK to define extension points, open authoring sessions for a tenant and run published versions.
- Hosted authoring with planning, coding and independent review
- Or bring your own AI and submit artifacts directly
- Secure setup pages for each customer's credentials
- Tests required before every publish, plus version history and rollback
- Tenant-scoped keys for authoring and execution
import { BrixLab } from 'brixlab';
const owner = new BrixLab({ token: process.env.BRIXLAB_TOKEN });
// Define what your customers may build.
await owner.define({
key: 'agent-custom-tools',
usage: 'ai-tools',
capabilities: {
multipleTools: true,
externalHttp: true,
secrets: true,
},
});
// Run a customer's published tool from your agent.
const runtime = new BrixLab({ token: tenantExecuteToken })
.use('agent-custom-tools');
const result = await runtime.run({
tenantId, implementationId, resource, input,
});Safe by construction
Fresh isolate per run
No module state between runs, no ambient network, no bindings to your data and a bounded CPU budget.
Reviewed permissions
Hosts, credential use and token exchanges are part of a permission plan the customer approves. Editing code can't widen it.
Placeholder credentials
Secrets are encrypted at rest and substituted by the gateway only for approved hosts. Responses are redacted before code sees them.
Clear failures
Failed runs keep the exception and the failing HTTP calls, with secrets masked, so customers can fix their extension.