What it's for
Jira, GitHub, GitLab, and Confluence all work over a public API. An on-prem agent is for whatever doesn't: a self-managed source-control or CI instance behind a firewall, an internal wiki, a test suite that needs to run against services with no public endpoint at all. It's a small process you run inside your own network — On-prem agents → Register an agent.
Outbound-only, always
The agent polls us for work and reports back; nothing here ever opens a connection into your network. There's no inbound port to open, no firewall rule to add for us — the same shape every satellite agent in the Noviqent fleet uses.
Two kinds of job
Context commands are fixed, read-only commands you configure once — run on every ticket fix, their output folded into gathered context alongside source code and runbooks. This app has no way to enforce read-only-ness remotely, since the agent runs entirely inside infrastructure you control: configure only commands that can't change anything.
A test command is one fixed command, run only in the environment you name (never production) — alongside your draft PR's own public CI, not instead of it. Both have to pass before a ticket fix is marked ci_passed.
The model can ask for more, once
If your organisation has an agent registered, the AI reasoning step can request additional read-only commands when it doesn't yet have enough to propose a fix. You'll see the agent run them, and it's asked exactly once more with the results added — never an open-ended loop.
Set it up
- On-prem agents → Register an agent
- Name it, optionally add read-only context commands (one per line) and a test command with its environment
- Copy the API key shown once, and configure your own agent process with it
- Point your agent at GET /api/v1/agent/jobs/next to poll for work, and POST /api/v1/agent/jobs/{id}/complete to report back