I used to think a "better model" would fix my agent loop. Then I gave the same model a GitLab CLI, read-only access to dev/test logs, and a browser that can open a preview URL.
The model did not get smarter. The harness did. Most "agent quality" problems are missing observation surfaces, not missing IQ.
Yes, the title is rude on purpose.
The loop that actually ships
Stop imagining agents as autocomplete with confidence issues. Treat them like a junior engineer on a good day:
Without tools, the agent only gets the build and a hopeful correct. You become the observability layer by pasting stack traces like a medieval scribe.
With tools, the agent closes its own loop.
Three non-production quality gates I actually use
These are deliberately boring. That is why they work.
1) gcloud CLI on **dev/test** logs (never production)
When a Cloud Run service misbehaves in a preview environment, the fix is usually in the logs. Paste culture means you play telephone. Tool culture means:
Wire that behind a scoped MCP tool or an allowlisted shell skill. The agent reads the failure, patches the code, redeploys the preview, reads again.
Hard rule: production logs stay human. Dev and test are fair game. If your security team cannot tell the difference in the credential, you have already lost.
2) GitLab CLI querying CI
Agents love declaring victory after a green unit test on their laptop. Cute. Ask the pipeline.
Now the loop includes "did CI actually succeed on the branch I just pushed?" That single question kills a shocking amount of false confidence.
Same pattern works with gh on GitHub. Pick the forge you already live in. Do not invent a custom CI MCP until the CLI is too awkward.
3) Agent Browser on preview links
UI bugs do not live in tsc --noEmit. They live in the running preview.
Point a browser tool at the Vercel/Netlify/Cloud Run preview URL. Click the path. Screenshot the failure. Read the console. Come back with a patch that addresses what a user would see, not what the compiler shrugged at.
This is the difference between "tests pass" and "the button still does nothing".
Context surfaces beat clever system prompts
Beyond those three gates, the useful tool list looks like the rest of your day job:
Each one removes a place where you would otherwise paste context by hand and introduce transcription errors.
Credentials: be adult about this
"Give the agent more tools" is not "paste the org owner token into .env".
Practical defaults I will defend in a design review:
Mischief is welcome in titles. It is not welcome in IAM.
What "10x" actually means here
Not ten times the commits. Ten times fewer human round-trips between "I think it's fixed" and "I can see it is fixed".
Same model. Tighter loop. Better tools. Honest scopes.
Thoughts
If your agent cannot observe the system it just changed, you do not have an engineer. You have a very articulate guesser.
&w=3840&q=75)


