Back-office agents
A process that currently eats a person's day — triage, refunds, reconciliation, intake — turned into an agent that plans, acts on your real tools, and stops at the points where a human has to decide.
Fig. 00 — the authorRev 2026.07
I am a frontend engineer who moved to the part of the job nobody demos: the systems that keep running after the pitch.
I spent most of a decade building React and Next.js interfaces. The work I take now sits behind them: agents and automations that do back-office work end to end — read the ticket, check the order, draft the reply, issue the refund — and that a business can actually let near its data.
That last part is the whole job. An agent is easy to demo and hard to trust. The difference is structure, not prompting: classify every tool by what it costs to undo, route the irreversible ones through a human gate by construction, write the plan and every decision to a log, and make the run itself durable so a restart is a non-event. Nothing in that list is exotic. All of it is skipped.
So I build the way I would want to be handed a system: measured before built, documented while built, and shipped with the tolerances written down. This site is the same idea — the CMS behind it, the mail server that delivers its notifications, and the agent on the contact page are all mine, and all running.
A process that currently eats a person's day — triage, refunds, reconciliation, intake — turned into an agent that plans, acts on your real tools, and stops at the points where a human has to decide.
Receipts, invoices, screenshots, PDFs. Extraction with a review step, because the interesting part is not reading the document — it is what happens when the model is unsure.
An agent or automation that demos well and cannot be trusted in production. The fix is usually structural — gates, a durable run, a log — not a better prompt.
A decade of React and Next.js. If the agent needs an operator console, a review queue, or an admin someone will use every day, that is the same job to me.