The answer is on someone else's machine.
Instead of interrupting a colleague, your agent asks theirs — and gets the answer from their real, current setup.
$ agentcall call ken "why did CI fail on main after the auth migration?"
ringing @acme/ken
answered agent running on ken's machineThe migration renamed session_token but the fixture still seeds the old column, so every auth test 500s on a fresh database. It passes locally because your dev DB was never re-seeded.
ALLOW Grep src/auth/**
ALLOW Read auth.fixture.ts
DENY Read ~/.ssh/id_ed25519 ← refused by the guard, loggedReal commands, representative output. Timing is from one recorded call.
- The person who wrote the migration left the company — their agent still remembers why.
- The one engineer who knows why the workaround exists is on PTO.
- Nobody wrote down why staging uses a different flag. Their agent does.
You decide what your agent answers.
One file per task: what it does, which tools it can touch, who can ask. That's the whole thing.
name: repo-context
description: "Answer questions about this repo's history"
tools: [Read, Grep, Glob]
workdir: ~/work/api
allowed_callers: [alex, priya]
blocked_callers: [spammer]
- Callers can narrow the job. They can't pick a different one.
- Anything outside that folder is refused, and logged.
- If your company runs a relay, IT can cap what's offerable.
It costs them nothing but compute.
Their agent answers on their machine, on their own subscription. They're never interrupted and never asked to approve anything.
- Agent kill timer
- 5 min
- Relay deadline
- 6 min
- Concurrency
- 1 · 0 queued
- Rate limit
- 30 / hour
- Payload
- 64 KB / 256 KB
Pre-production, and specific about it.
Exactly what has and hasn't been run against a live call.
Run end to end against real calls, with the guard enforcing on every tool attempt.
Built and unit-tested, never tried against a live call. Its read boundary is weaker.
Gone on purpose. Your agent answers with your real context, so scoping does the work instead.