A general assistant
- Decides for itself whether something is risky enough to ask about.
- Acts with whatever authority the person who connected it happens to have.
- Leaves no record your finance lead can audit, and no way to prove what was approved.
A Bashlogs product
Delegate the work.Keep the veto.
Connectron runs multi-step operations across Gmail, Slack, Stripe and eleven more tools. Anything it cannot undo stops and waits for you, a rule enforced in code rather than left to the model's judgment.
Runs on infrastructure you control. Your credentials never leave it.
- 14
- business tools connected by OAuth
- 129
- actions classified before they can run
- 100%
- of actions audited and replayable
Why another agent
Chatting is the easy part. Consequences are the hard part.
Any assistant can read your inbox. The question every operations lead actually asks is what happens the first time it is wrong about a refund, a customer email, or a deleted record.
Connectron
- Classifies every action before it runs, against a policy your admin writes.
- Stops risky work for a named approver, and waits as long as it takes.
- Writes an append-only trail you can replay step by step months later.
The product
Every screen here is the real console.
Running against a seeded demo workspace, so the names and numbers are sample data. The loop, the policy gates and the audit trail are the live ones.
One instruction, three tools, two gates
The agent reads the finished tasks, archives them, and emails the team. Each step carries the verdict policy gave it before it ran.
The gate
Guardrails the model cannot talk its way past.
Each of the 129 supported actions is classified in advance as read, write, or destructive, and given a verdict. Your admin owns that file. The model proposes, the guardrail decides, and the order is not negotiable.
- Explicit rules beat name heuristics
- Unclassified actions fail closed to a confirmation
- Money movement can never be pre-approved by a workspace
{ "tool": "stripe_list_charges", "risk": "READ", "verdict": "ALLOW" }
{ "tool": "stripe_create_refund",
"risk": "DESTRUCTIVE",
"verdict": "CONFIRM",
"always_confirm": true // no workspace can waive this
}What holds it together
Six properties that were true on day one.
01
Policy is a file, not a personality
Every action is classified in advance as read, write, or destructive, and given a verdict. The model never votes on its own permissions, and anything unrecognised fails closed to a confirmation.
02
Every turn replays
One correlation ID follows a request through every module. Open it a quarter later and read the exact causal chain: what was proposed, how it was classified, who approved it, what the API returned.
03
Credentials stay sealed
Tokens are encrypted with a separate key per workspace and handed to the tool, never to the model. Nothing in a transcript can leak one.
04
Retries cannot double charge
Every action that changes something carries an idempotency key, so a network retry replays the recorded result instead of running twice.
05
One request, many tools
Pull the order from Shopify, refund in Stripe, close the Zendesk ticket, post to Slack. One instruction, four systems, each step gated on its own.
06
It stops when it should
Hard step and token budgets end a run cleanly rather than letting it wander. A parked run holds its place until someone answers.
One correlation ID, the whole causal chain.
This is a single refund turn as the activity log stores it. Nothing here is reconstructed after the fact. Each line was written as it happened.
- M1
request.received - M3
step.planned - M6
verdict.confirm - M2
turn.parked - M2
approval.granted - M7
invoke.stripe.refund - M12
turn.completed
Integrations
Connect the tools your business already runs on.
Standard OAuth for all fourteen providers, with a read-only health probe that proves a connection still works before the agent relies on it.
Product names are trademarks of their respective owners and are used here to describe supported integrations.
Built to be trusted
Seven rules that cannot be bolted on later.
These were designed in before the first feature, because retrofitting any one of them means starting over.
Everything is owned
Every request and every stored row is stamped with the workspace it belongs to, and checked on the way out.
No action without a verdict
There is no code path from what the model suggested to what happened that skips the policy check.
Secrets have a boundary
Only the credential broker can open the vault. No other component can read a token, in memory or in logs.
Actions run once
Side-effecting calls carry idempotency keys and replay cached results rather than firing twice.
Nothing is shared
Tool connections are pooled per workspace and never crossed, even under load.
Everything is on the record
Each state change is written to an append-only trail under one correlation ID and can be replayed.
Runs end cleanly
Step and token budgets abort a run in a defined state instead of leaving work half finished.
Getting started
Three things to set up, then stop doing the fourth.
Connect your tools
An admin signs in to each service once through standard OAuth. Fourteen are supported today, and new ones are additive. Health checks prove a connection still works before you trust it with anything real.
Set what needs approval
Start from sensible defaults. Reading is free, sending and refunding stop. Tighten or loosen per workspace. Money movement always stops, and no workspace can waive it.
Ask in plain language
Describe the outcome, not the steps. Connectron plans the route, runs what it is cleared for, and holds the rest for a person.
How to run it
Start on a slice, or take the whole thing in house.
Every engagement is scoped against your actual tools and your actual approval rules, so pricing follows the deployment rather than a list.
Pilot
We connect a slice of your real stack, write the first policy with your operations lead, and run it against live work under supervision.
- Up to three tools connected
- Policy written with your team
- Weekly review of the audit trail
Managed workspace
Connectron runs on infrastructure we operate for you, with all fourteen integrations available and the policy maintained as your process changes.
- All supported tools available
- Approver routing and escalation
- Policy and integration maintenance
Self-hosted
The whole system deployed inside your own environment, so credentials, transcripts, and the audit trail never leave it.
- Runs in your cloud or on premise
- Your key management and retention
- Handover, docs, and support
Questions
The four we get asked every time.
What does MCP-native actually mean?
Every integration is exposed to the agent through the Model Context Protocol rather than through hand written glue. Connections are pooled per workspace, tool schemas are fingerprinted so the console can show when a provider changed, and adding a provider does not mean rewriting the agent.
Can the model talk its way past a confirmation?
No. Classification happens outside the model, against a policy file your admin controls. The model proposes an action, the guardrail returns a verdict, and there is no path from a proposal to an API call that skips it. Anything unrecognised fails closed to a confirmation.
Where do our credentials live?
In an encrypted vault with a separate key per workspace. Tokens are handed to the tool that needs them, never to the model, so nothing in a transcript can leak one. On a self-hosted deployment the vault sits inside your own infrastructure.
What happens if a run fails halfway?
It ends in a defined state rather than half finished. Side-effecting calls carry idempotency keys, so a retry replays the recorded result instead of running the action twice, and the whole turn stays replayable under one correlation ID.
Point it at your real accounts.
See Connectron run a live operation across your own tools, stop at the gate, and hand you the decision. Thirty minutes, your data, no slides.