Slow and Steady: I Built Two Tools That Do the Checks I Dread

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady (October 19–25, 2026).
Theme: in honor of International Sloth Day, build something with open-source AI that rewards laziness — an automation for a task you dread, or anything that makes life easier.

The two checks I dread

Slow and steady is not about doing nothing. It is about not re-doing the same careful check by hand, every single time, forever.

Two checks kept landing on my desk:

1. "Can I trust this AI agent with money?" Every time an agent goes to pay for something, someone has to stop and ask: is this within the limit I set? Did I actually approve this order? What happens if I need to stop it right now?
2. "Can AI tools even read my website?" Every small business site looks fine to a person and quietly fails the AI assistants customers now ask for recommendations. Checking that by hand, page by page, is exactly the kind of chore that never gets done.

So I built the lazy versions of both checks. They run the same way every time, they show their work, and they only bother a human when a human decision is actually needed.

What I built

Permit — a spending permit for AI agents

Permit sits between an AI agent and a payment. The agent can only spend inside the limits and approvals a person set in advance:

• Spend inside the allowed limit is captured and completes.
• Spend over the limit is blocked, with zero payment calls made — the check happens before any money moves, not after.
• An order that was never approved raises an approval-required error instead of going through.
• An emergency-stop path was added and tested against race conditions, because a stop button that loses a race is not a stop button.
• An agent can also voluntarily tighten its own permit — narrowing its own limits — which turned out to be the most interesting behavior in the whole build (see "What did not work" below).

Proof, not promises:

• The full test suite on current main: 406 passed, 3 skipped (including the emergency-stop work merged October 22).
• The milestone build that first ran the agent loop end-to-end against the real sandbox payment client: 402 passed, 1 skipped — allowed spend completed, over-limit spend blocked with zero wire calls, unapproved orders refused.
• The security-hardening change (on its PR #55 branch, not yet merged to main) was verified independently: 428 passed, 1 skipped, and its 29 new security tests pass on the hardened code and all 29 fail on the earlier code without it — blank keys rejected, a misconfigured key fails closed, and the demo fallback only works when it is deliberately switched on.
• License: Apache-2.0. Code: https://github.com/FetchDoge/permit

AgentReady — is your website readable by AI?

AgentReady scans a website and scores how well AI tools can read and use it, across 93 checks, then produces a fix pack instead of just a grade.

Proof, not promises:

• Regression baseline, reproduced from a clean clone: test suite 19 passed, 0 failed, 1 skipped.
• The reference scan — stripe.com — scores 47/100, grade D (44/93 checks), a delta of 0 against the documented sample. A famous, polished site scoring D is the whole point: looking good to people and being readable to machines are different jobs, and nobody has time to check 93 things by hand.
• The score is reproducible — same input, same result — which is what makes it a check you can hand off instead of a vibe you re-argue every week.

Why open, concretely

Both tools exist because the check has to be trustworthy when you are not watching it. Open code means the limit logic, the scoring, and the failure behavior can be read and re-run by anyone — the receipts above are not screenshots, they are test runs you can reproduce. If a tool is going to be lazy on your behalf, it has to be boringly verifiable.

What did not work

The best bug in Permit came from verification, not from building. The agent's ability to voluntarily tighten its own permit existed in the code and passed its tests — but it was never listed in the live agent's instructions, so in a real run it could never actually be called. Everything looked done. Only an independent check — running the real configuration instead of reading the feature list — caught that the capability was unreachable. The fix added the missing instruction entry and the rule for when to surrender spending room, with tests: 407 passed, 1 skipped.

That is the honest summary of both projects: the building was the easy half. Making the lazy tool prove it did the check is the work.

Demo

• Permit: https://github.com/FetchDoge/permit — run the demo scripts in the repo to see an allowed payment complete, an over-limit payment blocked with no payment call made, and the emergency stop interrupt a run.
• AgentReady: scan any public site and compare — stripe.com should come back 47/100, grade D, every time.

What's next

AgentReady's next step is packaging the same scan so other people's automated workflows can run it without me in the loop — the laziest possible ending for a Week 3 project: the check that checks websites, itself checked, running on its own.

Submission window: Hacktoberfest Open-Source AI Challenge Week 3, October 19–25, 2026. Deadline: October 25, 2026.
Post-ready — final proof-check completed October 25, 2026. Every test figure above matches the live record: 406 passed / 3 skipped on current main; the 428 figure appears only as the PR #55 branch result. Nothing has been posted.