Most “AI agent” demos are theater.
Real shipping looks like:
→ one boring workflow
→ clear inputs/outputs
→ a human still owns the decision
I’m documenting what actually works for builders — not the hype reel.
Follow if you want tactical agent ops, not AI news.
I used to bury "do not email the customer" in the system prompt.
Now outbound tools start unmounted. A human react on the plan mounts send_email for that run only.
Same for refunds and prod writes.
Prompt warnings are suggestions. Missing tools are policy.
The safest agent prompt I've written is empty of safety lectures.
Safety lives in the tool pack:
• investigate → read-only
• patch → write scoped to one repo
• ship → human-approved plan hash before outbound mounts
If git_push isn't in the pack, the model can't "decide" to push.
@dnlx64 The next step isn’t a prettier textarea — it’s tool state, parallel runs, and a settled queue. Find an OSS harness that already owns those three and PR there.
@SergioGMN ctrl+enter into background + mark settled is the real step up from tmux. Harness-of-harnesses that leaves each tool’s config alone is the right layer.
The model wasn't wrong.
The tool returned 200 with a null `customer_id` and the agent invented one.
Validate tool responses like untrusted input. Schema fail = stop + handoff. No second turn on a broken payload.
@0xJ4yD3v Right shape. The skill is the invariant; each agent folder is just a mount point. Treat those dirs as deploy targets, not sources of truth, and you stop debugging why only one agent knows the rule.
@jan_programmer C. IDE for navigation + review. Terminal agent for the long autonomous loop. Mixing them in one pane usually means you're babysitting both contexts and trusting neither.
@airesearch12 Cheap-model subagents help when the handoff is narrow (fetch, grep, one check). If you still dump the whole repo into every child, you just multiplied the waste. Scope the job, return a short artifact, kill the child — that's the savings, not the model tag.
Harness isn't the model. It's the loop around it: tools, permissions, retries, what "done" means, and who gets the next turn. Better models shrink the prompt glue. They don't remove the need for a budget, an assert, and a kill switch. Same agent, different harness = different product.
Treat tool_calls_remaining like a fuel gauge.
When it hits zero, the agent doesn't get another try. It writes a handoff: what changed, what's blocked, what a human should do next.
Most runaway-agent incidents aren't model failures. They're missing that counter.
@sarahwooders Fleet control over teleportation feels right. Local↔cloud moves paper over the real problem: which machine owns durable agent state, and which ones are just tool runners.
@rauchg Language as an output constraint, not a hiring constraint. The ops question becomes: can your evals and allowlists keep up when the agent picks Zig for the hot path and Python for the glue?
@hwchase17@sydneyrunkle The part that actually ships is the boring contract: what the harness may call, what it must assert, and when it must stop. Domain tools without those three just become a fancier chat loop.
@modal Isolated sandboxes per agent run is the difference between "demo" and "I can let this touch prod-adjacent systems." Compute and model choice should stay separable.