What it is
Your team says the job. Agents do it on your servers.
Loopgate runs coding agents, Claude Code, Codex and pi, as workflows on a server in your own cloud. Someone on your team says the job in a Slack thread. Before anything runs, one card shows who works it, each step's model, the access and the most it may spend. One agent builds, another on a second model reviews, your own commands check the result, and the questions come back to the thread as buttons. Nothing ships until a person presses.
For teams, we set it up with you: the server, Slack, the tools your agents need, and the agents and workflows for your first jobs.
From one Slack thread, the whole job
-
Build features
A planner writes the plan and you lock it. A builder builds it, and a reviewer on another model sends it back for fixes, for the rounds you set. The pull request opens when you press.
plan-build-review · built in
-
Debug production
Two investigators on two models look at the same incident at once. A lead writes one root cause from both, then you choose: fix it under review, or keep the report.
root-cause-fix · built in
-
Read logs and metrics
On your server an agent can run what the server can: your log and metrics tools, your tracing, kubectl. It uses the credentials you put there, read-only to start.
your tools · your credentials
-
Work your infrastructure
AWS, Google Cloud and Azure through their own CLIs and SDKs. A workflow can stop for a person's approval before the step that changes anything.
an Approve gate before the change
-
Ship and deploy
Build, then your test command, then review, then your approval, then your deploy command. Each command's exit code decides where the run goes next.
a workflow we shape with you
-
Work as a team
Anyone in your org opens the run, reads every word each agent was told and replies to any step. A decision can wait for a named teammate, who is asked in the thread.
one run, the whole team
Where it runs
On your cloud. Your team stays where it works.
One Linux machine with Docker is the runner: in your AWS, Google Cloud or Azure account, on any VPS, or the box under the desk. The agents work there, so a run keeps going when a laptop closes.
Your team
- Slack. Say the job in a thread, answer with buttons.
- The workbench in a browser, at your own address.
- Their own Claude Code, Codex or pi, starting runs on the server.
Your server, the runner
- Loopgate, one container.
- Claude Code, Codex and pi, signed in with your team's plans.
- Your tools: your cloud's CLI, your logs, kubectl, gh, and the connectors we build.
- Your repositories, each run in a worktree of its own.
Loopgate's portal
- Your members and their roles.
- Your policy: which engines, whether Full access is allowed, banned commands.
- A record per finished run: who, when, the workflow and models, how it ended, what it cost.
Stays on your server
Your code and every diff. What each agent was told and said. The task. Your Claude and ChatGPT sign-ins. Your cloud credentials.
Reaches Loopgate
A heartbeat, your team's member list and a record per finished run. Revoke the runner in the portal and nobody reaches it within a minute.
Live in a week
Five days from the first call to your team running it.
We do the setup with your engineers, in your own accounts. You see every step and keep everything we build.
-
Day 1 · Map
Pick three jobs
A call with your leads. We choose the first three jobs your team would hand to agents, and what done means for each.
Three jobs, written down
-
Day 2 · Install
Put the runner on your cloud
One install line on a machine in your account, about thirty minutes. Claude Code, Codex and pi signed in with your team's plans.
Your server, running
-
Day 3 · Connect
Give the agents their tools
Slack and GitHub, then what the jobs need: logs, your cloud, tickets. Read-only credentials first, each one scoped by you.
Agents that can see
-
Day 4 · Shape
Build the three workflows
Agents and workflows for each job, tried on real tasks, with a person's approval wherever your team wants one.
Three workflows, tried
-
Day 5 · Hand over
Your team runs it from Slack
We watch the first runs with you and tune what needs it. From here, a new job is a new workflow, built with us or by your team in the builder.
Your team, running it
Agents for specific jobs
One workflow per job, with checks where it counts.
A workflow is a few agents taking turns on one task, each step on its own model, with your commands and your people at the points that matter. Many come built in. The rest we shape with you.
| The job | Who works it | Ready |
|---|---|---|
| Ship a feature | A planner whose plan you lock, a builder, a reviewer on a second model | Built inplan-build-review |
| Find why production broke | Two investigators on Claude Code and Codex, then a lead who writes the root cause | Built inroot-cause-fix |
| Split a big change | An orchestrator writes a brief per lane, runs each lane on its own model, verifies | Built inorchestrator-lanes |
| Change many packages at once | Builders take one work item each, a lead verifies the merged work | Built inwork-items |
| Review for security and quality | Security and quality reviewers in parallel, a fix, then your decision | Built inreviewer-panel |
| Audit a repository | Cloudflare's security-audit skill, with every fix verified on its own | Built insecurity-audit |
| Release to staging | A build, your tests, a review, your approval, then your deploy command | Shaped with you |
| Triage an alert | Mention Loopgate in the alert's thread; an investigator reads the logs and replies | Shaped with you |
Custom connectors
When a tool has no way in, we build one.
Agents reach a tool through a command line or an MCP server on the runner. Where yours has neither, we write the connector: scoped to what the agents need, kept in your repository, yours to change.
- Your internal admin API
- Feature flags
- Your deploy system
- Linear and Jira
- PagerDuty and Opsgenie
- Sentry
- Datadog and Grafana
- Snowflake and BigQuery
What stays in your hands
The agents do the work. Your people decide.
-
Nothing ships on its own
A pull request opens when someone presses. A workflow can stop for a person's approval before any step that changes something.
-
A ceiling on every task
An admin sets the most a Slack task may spend, in dollars and hours. Every loop stops at the rounds you set.
-
Full access, said out loud
From Slack, agents work with Full access unless Customize lowers it, and the card says ⚠ Full access before Start. Your org policy can forbid it.
-
Your policy, checked every time
Which engines, which banned commands and whether Full access is allowed are set once for the org and checked at every start and every decision.
-
Every word on the record
Every word each agent was sent can be read, before and after. The thread is the record of the task, from the card to the finish.
-
Your keys stay yours
Loopgate holds no key and never sees your sign-ins. Credentials live on your server, scoped by you. Revoke the runner and nobody reaches it within a minute.
Questions
What teams ask before the call.
What is an AI layer for an engineering team?
Agents that do engineering work, building, debugging, reviewing and shipping, inside the tools your team already uses. With Loopgate they run as workflows on your own server, take their work from Slack, and a person decides what ships.
Can the agents read our production logs?
Yes, on your server, with the credentials you give it. An agent runs the same command lines your engineers do, such as your cloud's log tools or kubectl. We start every connection read-only.
Can agents change our infrastructure or deploy?
Only through a workflow you approve. A deploy is your own command, run as a check, and a workflow can stop for a person's approval before it. No pull request opens without a press.
Does our code leave our infrastructure?
No. Code, diffs, prompts and transcripts stay on your server. Loopgate receives a heartbeat, your member list and a record per finished run: who, when, the workflow and models, how it ended and what it cost.
Which models do the agents use?
The coding agents your team already pays for: Claude Code, Codex and pi, signed in with your plans. Each step picks its own model and thinking level, so one model builds while another reviews.
How long does setup take?
A week with us: the runner on day two, Slack and your tools on day three, your first workflows on day four and your team running them on day five. The runner alone installs in about thirty minutes.
Can you build a connector for our internal tools?
Yes. We build it as a command line or an MCP server on your runner, scoped to what the agents need and kept in your repository.
Do we need Slack?
No. The same runs start from the workbench in a browser, or from your own Claude Code, Codex or pi. Slack is the easiest way in for a whole team.
What does it cost?
Teams get a 14-day trial for five seats, and the agents run on your own Claude and ChatGPT plans. The setup week is priced on the call, for the jobs you pick.
Who will we work with?
The two people who build Loopgate. You book the demo with us, and we do the setup week with your engineers.
Book a demo
Bring one job. Leave with the plan for it.
Thirty minutes with a founder. We run Loopgate live, then sketch how agents would do your job on your own infrastructure, steered from Slack.
- A live run on a real repository, in the workbench and in Slack.
- Your setup drawn: your cloud, your Slack, the tools your agents would need.
- A plan for your first week, if it fits. If it does not, we say so.
You talk to the two people who build Loopgate.
Pick a time
30 minVideo call
Reading the calendar…
You are booked.