One Torque Talking To Another

Torque exists because not every delivery loop belongs in a hosted CI control plane. Some teams work in air-gapped networks, regulated environments, edge sites, customer labs, or recovery drills where runners cannot phone home and artifacts must stay close. In those places, the useful shape is CI in a box: build, verify, plan, apply, capture, and explain from one workstation, VM, or isolated build host.

Agentic engineering is not vibing. It is closer to serious programming with a larger test bench: you set up labs, virtual infrastructure, physical infrastructure when the problem needs it, and repeatable tasks that prove the agent can operate under real constraints. The agent still needs guidance, review, and product judgment. Someone has to shape the goal, sequence the work, check the evidence, and decide what is acceptable, much like a product manager or product owner does before a release. That is the operating style behind Ingress Labs: agents are useful when they are driven through real systems, not when they are left to improvise in a blank prompt.

Modern DevOps tools should be easy for an agent to drive and still comfortable for a human to inspect. The operator should not have to click every button by hand, but the agent should not get an open shell either. Torque sits in the middle: it gives agents named actions for building images, shipping releases, checking charts, reading logs, replaying sessions, warming caches, and reviewing evidence. Every action has inputs, outputs, and a trail another person or process can read later.

The bridge is the key idea. A Mac-based agent can call torque-mcp as a local tool server, while a Linux host does the real build and deploy work through torque-agent. The model asks for a task in a small, typed format. Torque forwards it to the remote service, redacts sensitive output, and returns evidence instead of a wall of terminal noise.

The safety model is deliberately plain. Local agent calls use stdio or authenticated loopback HTTP. Remote work uses a dedicated agent service, scoped credentials, and durable session storage. Write actions stay off until they are enabled, and mutating requests still need confirmation. Tokens live in environment files instead of command arguments, secrets are scrubbed from responses, and every build or deploy leaves a capture, report, summary, or replayable session behind.

The same posture is now installable as a Linux daemon path. install.sh --mode systemd-daemon installs torque, torque-agent, and torque-mcp, writes /etc/torque/agent.env, and starts systemd services for the remote agent and local MCP server. The agent runs in durable mode, stores session frames under /var/lib/torque/agent/mirror.sqlite, and turns sandboxing on for remote builds. That makes the agent suitable for long-running build hosts instead of one-off terminals.

The cache workflow follows the same agent-first design. Instead of making a model read BuildKit logs and guess what happened, Torque gives it three clear tools: inspect the cache setup, plan which layers are affected by changed files, and warm the remote cache when a human or policy allows it. The agent can prepare the build path, but the project keeps cache writes bounded and reviewable.

Two of the nicer human-facing features are the verifier report (https://ingresslabs.github.io/torque/showcase/reports/verifier-report.html) and Helmer plan report (https://ingresslabs.github.io/torque/showcase/reports/helmer-plan.html#resource=showcase:deployment:verify-findings-showcase). The verifier report turns policy findings, risk levels, skipped checks, and release blockers into a reviewable page instead of raw JSON. The Helmer report does the same for rendered Kubernetes resources: reviewers can inspect the plan, jump to a specific deployment, and compare what an agent proposes before anything touches the cluster.

The broader project is built around the same idea. Torque can build containers, package charts, verify policy, plan Kubernetes changes, apply or delete stacks, follow logs, explain captured runs, and preserve evidence as files that move with the incident or release. The new agent surface does not replace those capabilities. It makes them callable by an agent without hiding what happened.

That is the direction modern DevOps tooling needs to move. Humans should design policy, approve risky actions, and debug the hard cases. Agents should handle the repeatable path: gather context, propose a plan, run bounded tools, warm caches, collect logs, and return evidence. Torque gives that loop a narrow interface and a durable paper trail, so automation can move faster without turning delivery into a black box.