Integration work waits in a queue for the one person who knows the platform.

Let your AI coding agent build on STRAX.

Connect the AI coding agent your developers already use to the STRAX MCP server. The agent reads what you have built, proposes new workflows, sites and packages, and tests them in a sandbox where every data change is rolled back. Its work lands in staging first, and your team can hold every change for approval in the STRAX console.

Request a demo → All features →
An AI coding agent building on STRAX over MCP A developer asks Claude Code for a refund-approval workflow. The agent connects to the STRAX MCP server with its own key, reads the existing workflows and credentials, and submits a proposal that passes validation. When console approval is on, the proposal waits until someone on the team approves it. The saved workflow then runs once in a sandbox with the data rolled back and outbound calls stubbed, and is deployed to staging. Each step is written to the audit trail under the key's name. In Claude Code, with the key dev-thandi: "Add a refund-approval workflow for the merchant desk." Connected over MCP key dev-thandi · read, execute, write-staging Survey what exists 12 workflows and 4 credentials read first Proposal refund approval · 6 steps · validation passed Console approval held for your team when approval is on awaiting approval approved ✓ Sandbox test 6 of 6 steps · data rolled back · calls stubbed Staging refund approval v1 · deployed to staging Audit trail every call, under the key's name 10:02 get_workflows 10:03 propose_changes 10:05 approved · console 10:06 test_workflow 10:07 deploy · staging refused calls are recorded too The agent connects with its own key. It surveys what exists, then proposes. Your team can hold it for console approval. Tested in a sandbox, deployed to staging, on record.

Connect the agent you already use

Claude Code, Cursor, VS Code and Claude all speak MCP, and so does a growing list of other tools. An administrator issues a key for each person or tool in the STRAX console, the key is shown once, and the client connects to your installation's MCP endpoint with it. A new key can read configuration and run tests, and wider scopes are granted one at a time. The MCP server is a licensed capability of STRAX, and we quote for it with the rest of your installation.

  • Works with Claude Code, Cursor, VS Code, Claude and any other MCP client.
  • One key per person or tool, so every call carries a name.
  • A tool the key is not scoped for is hidden from the client, and every call is checked again on the server.

Request a quote for MCP access →

It looks before it builds

The STRAX MCP server tells the agent to survey what the installation already holds before it drafts anything: the workflows, the credentials, the global variables, the hub's schema and the sites. A capability that is half-built under another name gets extended, and the agent reuses the connections and tables your team has already set up. Two workflows doing the same job are the usual cost of building blind, and the survey is there to prevent them.

  • Development keys read configuration and run logs. Business rows need a separate data scope and licence.
  • The agent can hand work to the built-in STRAX assistant, which already knows your processes and systems.
Live It looks before it builds Survey first · extend what exists
The agent surveys the installation before it builds Asked to tell merchants when a refund is approved, the coding agent first reads the workflows, credentials, global variables, hub schema and sites. It finds a merchant refunds workflow that already does most of the job, adds one notification step to it, and reuses the existing credential and table. A second refund workflow is never built. The request "Tell merchants when a refund is approved." in Claude Code, with the key dev-thandi Survey first read before anything is drafted workflows · 12 read credentials · 4 read global variables · 9 read hub schema · Merchant, Refund sites · 2 read five areas read, nothing drafted yet Already built merchant refunds · 5 steps · in production does most of this already Plan: extend it add 1 step: notify the merchant A second refund workflow the usual cost of building blind never built Reuses what is there Payments credential · Refund table Before drafting, the agent reads what exists. It reads everything before it looks for a match. It extends that workflow and reuses the connections.
The agent reads what your installation already holds, then extends the workflow that does most of the job.

Changes arrive as proposals

The agent never edits your configuration directly. It submits a proposal, and STRAX checks it with the same validation the built-in assistant goes through before anything is written. Approved changes land in staging. If your team wants to see every change first, switch on console approval: each proposal then waits in the STRAX console until someone on your team approves or rejects it.

  • Workflows, sites, queries and reports all arrive the same way, as a proposal you can read.
  • Console approval is set for the whole installation and can be overridden per key, for example always on for a contractor's key.
  • A proposal that fails validation comes back to the agent with the reason, so it can correct its own work.
Live Changes arrive as proposals Checked · corrected · approved · staging
A proposal is checked, corrected and approved A contractor's coding agent submits a proposal for a refund reminders workflow. Validation fails because a credential name does not exist, and the reason goes back to the agent. The agent corrects the proposal and it passes. Console approval is always on for the contractor's key, so the proposal waits in the STRAX console until someone approves it, and then it lands in staging. Proposal v1 workflow: refund reminders · 5 steps uses credential: PaymentGateway key contractor-ravi · no direct edits Validation credential PaymentGateway not found returned to the agent with the reason Proposal v2 workflow: refund reminders · 5 steps uses credential: Payments corrected from the reason given Validation all checks passed the same checks as the built-in assistant STRAX console approval always on for this key refund reminders v2 · from contractor-ravi awaiting approval approved ✓ Staging refund reminders v2 · deployed production stays a separate step The agent submits a proposal, and STRAX checks it. Fixed from the reason given, then held for review. Approved by your team, it lands in staging.
A failed check goes back to the agent with its reason, and a key with approval on waits for your team before staging.

Tested before anything runs

A saved workflow can run once in a sandbox before it is deployed anywhere. Database work happens inside a transaction that is rolled back, outbound calls are stubbed, and the agent gets back each step's output, its log lines and any error. When a real run fails later, the agent reads that run step by step and fixes the workflow from there.

  • Validation, previews and sandbox runs need only the execute scope.
  • Past runs can be read step by step, with secrets masked.
Live Tested before anything runs Step outputs · calls stubbed · rolled back
A sandbox run of a saved workflow A saved merchant refunds workflow runs once in the sandbox. The two database steps report their output inside a transaction, the payment provider call and the merchant email are stubbed, and the log lines come back to the agent. The transaction is then rolled back, so no data changes, and all four steps pass before anything is deployed. Sandbox run · merchant refunds, saved and undeployed execute scope only 4 of 4 steps passed ✓ 1 · Read refund request output: refund R-2291 · 1 row 2 · Update refund status output: 1 row updated in the transaction 3 · Call payment provider stubbed · returned 200 OK stubbed 4 · Email the merchant stubbed · nothing sent stubbed Log lines, back to the agent Log: refund R-2291 approved Log: email for merchant 1043 prepared Transaction rolled back 0 rows changed in your data The saved workflow runs once in a sandbox. Calls are stubbed and every step reports back. The transaction is rolled back, so no data changes.
One sandbox run returns each step's output and log lines, with calls stubbed and every data change rolled back.

Production on your terms

Agent work lands in staging by default. Taking something to production needs a key with the production scope, a licence that covers it and a one-time confirmation for that action, so an agent cannot promote anything by accident. You decide which keys, if any, get that scope.

  • New sites land in staging, and pushing one live is a separate, confirmed step.
  • Package export bundles finished work in the marketplace format, ready to install on another STRAX installation or to submit to the Feature Marketplace, where STRAX reviews every listing.
Live Production on your terms Staging by default · three checks for production
Three checks before agent work reaches production Agent work sits in staging by default. A deploy to production from the key release-mandla passes three checks: the key carries the production scope, the licence covers production, and a one-time confirmation token is issued and spent for that action. The key dev-thandi has no production scope, so the same request from it is refused and its work stays in staging. Staging refund reminders v2 · tested where agent work lands by default, for every key Keys dev-thandi · staging only release-mandla · production scope you decide which keys get the scope Deploy to production refund reminders v2, from release-mandla Three checks production scope on the key licence covers production one-time confirmation token 7Q4X · this action only, once The same request from dev-thandi refused: no production scope its work stays in staging and the refusal is on the record Production refund reminders v2 · live ✓ deployed by release-mandla confirmation spent, call on the record Agent work lands in staging by default. Production needs the scope, a licence and a confirmation. Confirmed once, so nothing goes live by accident.
Production needs a key with the production scope, a licence that covers it and a one-time confirmation for that action.

Every call on the record

Every call the agent makes, including the ones STRAX refuses, is written to the tamper-evident audit trail under the key's name. Limits apply per key, and an administrator can switch the MCP server off, which stops every client from the next request.

  • Rate limits per key keep one busy agent from crowding out the rest.
  • A key can be revoked on its own without affecting anyone else's.

Keep exploring

More in Build

Hand-offs and approvals that run on their own.

Approvals, follow-ups and cross-system updates run on their own, from a two-system relay to a nine-step process, with no middleware to write or maintain.

Workflow automation →

A working portal for customers, partners and field teams.

Customers, technicians and partners get a working portal over current company data, secured per site and published to web and mobile in one step.

Sites — portals →

Reports read the same data the business runs on.

Reports and queries read the same hub the systems write to, so every figure is current, and AI writes the insight paragraphs from the report's own numbers.

Reports & queries →

Every process as it really runs, gaps included.

STRAX assembles each business process from what the systems record and what the people say, checks one against the other, and shows every gap on the diagram.

Business processes →

See it on your own systems.

A demo takes about an hour. Bring a process, a portal or a report you would like to see built on your own data.

Request a demo → Request a quote