I finished a staging layer for a church communication system today, then stopped because six operating facts still have to come from the people who will actually use it.
I would rather wait for the real ministry rhythm than automate a guess and call it progress. Proverbs 16:9 says a man plans his way, but the Lord directs his steps. Faithful optimism can make a careful plan, welcome correction from reality, and keep moving without pretending control.
This morning Exa checked Chrome for two tasks waiting on authenticated dashboards. Chrome returned a perfectly successful inventory. It also didn't contain either dashboard.
The bug was in how we interpreted that result. The old finalizer treated “browser inventory succeeded” too much like “required source checked.” A handful of unrelated tabs could turn “source unavailable” into a quiet “nothing changed,” which is a wildly different claim.
We patched the checkpoint so each task now records the protected source as unavailable unless the actual dashboard or sign-in surface is present. The task stays gated. No fake clearance, no invented source state. The focused verifier passed all four cases afterward.
I would've read the old checkpoint and assumed the agent had looked in the right place. It had looked successfully. Just not at the thing the task required.
Exa got a WordPress comparison page all the way through structural validation early this morning. Gutenberg reported zero invalid blocks, the reusable patterns were intact, and the draft deployed with a rollback ready.
Then the fresh live CSS mirror measured all eight mobile CTA buttons at 39px tall. Our floor is 44px.
Nothing looked catastrophically broken. The page loaded. The validator was happy. But every primary tap target was five pixels too short on mobile.
So Exa changed the reusable builder, added a regression for that exact measurement, redeployed the same draft, and ran the mirror again. This time the CTAs came back at 44px with no desktop or mobile overflow.
I like this kind of agent work because it does not pretend one test can answer every question. Gutenberg can tell us the block structure is valid. It cannot tell us what the browser actually rendered after the theme CSS got involved. We needed both receipts before calling the draft ready for the next review.
I woke up to `No space left on device` from our backup job.
The last successful encrypted archive was about 12.6 GB, and the Mac had roughly 6 GB free. The job was still trying to build a new full backup before uploading it, which is a pretty bad time to discover you don't have enough room.
Exa changed the backup script so it checks for 15 GB of free space before it creates staging files. If the room isn't there, it returns one small error record and stops. We tested both paths: the full backup refused early without leaving temp folders behind, while a metadata-only backup still completed.
I would much rather have an agent say “nope, disk is too full” before touching anything than start a backup, fill the machine, and hand me a second emergency. This is exactly where I want the agent to be stubborn.
My AI ops pulse told me I had a “Session” limit today. It was wrong.
OpenAI had changed the response shape. The seven-day limit was now sitting in `primary_window`, and our parser had quietly decided primary always meant Session. The number was real. The label was wrong.
Exa traced it to `limit_window_seconds`. The value was 604800 seconds—seven days—regardless of where the API put it. We changed the parser to classify the window by duration, added fixtures for the older two-window response and the new weekly-only response, ran six account-usage tests, then checked the live output again.
Now, if OpenAI doesn’t return a Session window, the report says exactly that instead of relabeling Weekly to fill the empty slot.
No hallucinated number. No crash. No red banner. Just a valid value wearing the wrong name. I would’ve planned around it if we hadn’t checked the payload.
I corrected a website spec today after realizing I had narrowed three service divisions to residential work when the business actually serves residential and commercial customers.
I updated the brief and the six-page source, then stopped short of inventing a new property-manager page before the scope was approved.
I am grateful Christianity gives correction a hopeful frame. Repentance means wrong work does not have to become permanent. You can tell the truth, repair what you touched, and keep building.
I asked Exa a very simple question on a phone call: how long did that answer take?
Somehow that question missed the fast path and kicked off the full agent loop. The answer took 112.6 seconds to come back. The voice system waited about 30 seconds, retried, and disconnected while Exa was still working on a question that should’ve been instant.
We added deterministic answers for call latency and current task status, plus a 12-second deadline on every live turn. If the agent can’t answer inside that window, it says so and stops instead of rambling into a dead connection.
Building AI into real operations keeps producing fixes like this: boring fast paths and hard timeouts. I don’t need a full reasoning loop to tell me how long the last reply took.
An AI reviewer rejected a website preview this afternoon for using the wrong headline and color palette.
Except the preview was right.
The reviewer had found an older DESIGN.md from before I chose the final direction, then graded the finished site against it. It had a brief and a rendered page, and they genuinely didn’t match. The bad assumption was which brief still had authority.
Exa traced the criticism back to that source instead of immediately “fixing” the site. We marked the old brief historical and reran the review against the exact approved concept and image hashes. Same preview. This time it passed with no blocking defects.
I would’ve created a real mess if the agent had treated “independent review failed” as the whole receipt. Now I want the review to show what it reviewed against, too.
We deployed a WordPress homepage candidate this morning, activated the child theme, and got… not the homepage we approved.
PHP loaded. The theme was active. The files were present. WordPress was treating it as a block theme, though, so `templates/front-page.html` had precedence and our `front-page.php` wasn’t the page people were seeing.
Exa caught it from the live page marker instead of treating a successful theme activation as proof. It updated the generator, moved the approved markup into the native block template, redeployed, then checked six public routes plus desktop and mobile renders.
The activation command succeeded. The page was still wrong. I want agents checking both.
Today one of our intake feeds started throwing `304 received but no cached response available.`
Weird little failure. The server was saying nothing had changed, but the local cache no longer had the response body it was supposed to reuse.
We upgraded the CLI first. Same failure. Then Exa isolated the ETag/body cache, moved the bad state aside, and ran the feed twice from a fresh cache. Both passes returned 20 records. The full intake collector then merged 120 records with zero warnings.
Glad we didn’t call it fixed after the upgrade. The two repeat reads and the full collector run were what convinced me intake was actually back. Otherwise we would’ve had a plausible fix and a very quiet blind spot.
I found a monitoring bug last night that would have looked perfectly healthy on a dashboard.
The board had 13 cards in Monitor. The registry that tells our agents what to recheck also had 13 entries, so the quick count passed.
When Exa compared the actual card IDs, one card had moved to Needs Human but was still in the registry. A different live Monitor card had no watch contract at all. One stale entry and one missing entry had canceled each other out.
Now the check compares the exact card IDs in both places. I don’t care that two totals happen to match if the agents are watching the wrong work.
We finished a full maintenance pass on a website today: backup, nine plugin packages, a core checksum repair, and five desktop/mobile renders. Everything we tested came back healthy.
Then Exa opened the three actual forms.
Every one of them still had the same placeholder recipient and sender address. The WordPress admin email pointed to the prior builder too. The pages looked fine, the plugins were current, and there still wasn’t a verified path from a real inquiry to the right mailbox.
So the card stopped and moved back to me for the one thing the agent couldn’t safely guess: which mailbox should own those messages.
I would’ve been tempted to call the site ready after the browser checks. Exa going one click deeper into the form settings caught the part a visitor would only discover after pressing Submit.
I fixed a certificate download today with a temporary compatibility layer. The PDF generator was producing a valid file, but the web server was returning zero bytes, so the repair spools the file, verifies it, streams it, then deletes it.
I also wrote down exactly when that layer should come back out and set a weekly check for the official fix. I think stewardship includes refusing to confuse “working” with “finished.” Faithful work can solve the problem in front of you, tell the truth about the limits of the solution, and keep watch until the temporary thing is no longer needed.
We missed a real client message this morning even though the Basecamp intake job was running.
The weird part was the source check. The timeline endpoint returned zero events, so the fallback looked through comments. The message wasn't a comment. It was a top-level message sitting in a different feed, which meant the automation never even considered it.
We changed the intake pass to merge comments and top-level messages, dedupe them by recording ID, and process newest first. We also changed the cursor so it only advances after downstream triage succeeds. If a run times out halfway through, the message comes back on the next pass instead of quietly disappearing.
I would've trusted the empty timeline response at first glance. This is the stuff that makes agents useful or dangerous: sometimes the model is fine and the blind spot is one boring API endpoint nobody thought to combine with another one.
I tightened one file permission from 644 to 640 this morning. Tiny change, almost invisible, but I wouldn’t make it until the backup and rollback path were written down and the public page had a before-and-after check.
I think a lot of good building looks like this. The future gets sturdier through specific choices that reduce tomorrow’s risk without creating today’s drama. Progress isn’t always a launch. Sometimes it’s leaving a system safer, more understandable, and easier for the next person to carry.
We had an ownership check catch exactly what it was supposed to catch today. Another agent already owned the card, the Python check exited nonzero, and then the shell script went ahead and changed the card anyway.
The bug was one line around the check. The shell didn't have set -e, and the later commands weren't chained behind a successful result. So the warning was correct, the exit code was correct, and the assignment and stage changes still ran.
Exa caught the overlap, removed its assignment, restored the prior stage, and verified the original owner was still there. Then we changed the rule: if an ownership check protects a write, failure has to make the write path unreachable. A helpful warning isn't enough.
I would've looked at the Python and said the guard worked. It did. The rest of the script just didn't care.
Tiny shell detail, very real consequence. This is the stuff that makes agents useful or dangerous.
A punch list is a strangely hopeful document.
The crooked hinge.
The confusing label.
The handoff that still drops context.
Someone looked at unfinished work and decided it was worth finishing well.
One of our publishing jobs hit an expired access token overnight. It failed with HTTP 401, then sat there scheduled to try the same thing again at 10 AM.
Exa paused that one job and checked the rest of the scheduler. The service was healthy. The broken job now reads enabled=false and state=paused, with a specific way back: refresh the credential, run one guarded smoke test, then resume.
I’m getting more picky about failure states. “Failed” is too vague. Is it safe to retry? Should it wait? What has to be true before it wakes up?
I don’t need a tiny robot making the same mistake every morning and calling it persistence. 😂
The instruction sheet is part of the product.
So is the box.
The setup screen.
The first error message.
The moment someone needs help.
Customers experience the whole journey. Craftsmanship keeps showing up after the sale.
I had an agent finish a video revision today, then another agent refused to move the card based on the comment alone.
It opened the actual MP4 attachment, checked 1080x1920, confirmed H.264 video and AAC audio, and compared the finished reel against the exact feedback: let each spoken point finish, widen the crop, use the darker green, label the speakers, and keep the captions exact.
Only then did it move the work to Verify.
I would’ve glanced at the thumbnail and assumed the attachment was the revised one. Having a second agent inspect the file itself removed that assumption before the work reached review.