The parking portal for my building is simple, but it is still a task: open the site, enter the visitor's plate, choose the state, pick the duration, submit, and send back confirmation. That is exactly the kind of small, annoying workflow I like giving to an agent.

Hand-drawn flow showing a visitor sending a license plate photo over iMessage, an agent extracting details, filling the parking portal, and sending confirmation.
The happy path should feel like texting a picture, not learning a parking system.

The version I would build starts with a visitor sending me a rear-car photo over iMessage. The plate has to be visible. The agent reads the image, extracts the plate, asks for missing details, opens the parking portal in a browser worker, fills the form, submits it, and replies with the result.

The key design choice is that the model does not get to improvise the whole job. It gets narrow tasks: read the plate, normalize the state, decide whether confidence is high enough, and write a short message. The browser worker owns the actual portal interaction.

photo arrives
extract plate and confidence
ask for missing fields if needed
open portal in isolated browser
submit only after policy checks pass
send confirmation or next question

Most of the engineering is in the edge cases.

Hand-drawn edge-case state machine for a parking registration agent, including unclear plates, missing vehicle details, portal failures, duplicate registrations, and manual review.
A useful home agent needs a boring fallback for every confident-looking failure.

If the plate is blurry, it asks for another photo. If the state is missing, it asks one question. If two plates are visible, it stops. If the portal says the vehicle is already registered, it sends that as the confirmation instead of submitting again. If the portal changes layout, the browser worker should fail closed and ask me to review.

I would also separate unknown visitors from trusted ones. An allowlisted sender can register their own car within normal limits. A new sender triggers a one-time owner approval: "Register ABC123 for Maya for tonight?" That keeps the social workflow easy without letting any random message become a portal action.

The always-on part is less glamorous. iMessage makes the intake awkward because the cleanest personal setup is still an always-on Mac signed into a dedicated account. A small watcher can turn incoming messages into jobs, and a separate worker can handle OCR, policy, and browser automation.

Hand-drawn always-on architecture for a personal parking agent with iMessage intake, queue, OCR parser, policy checks, browser worker, secrets vault, audit log, and data retention.
The private parts are separated from the browser worker, and photos do not need to live forever.

For 24/7 reliability, I would keep the system small: a Mac mini or home server for message intake, a queue for retries, a browser worker that can restart cleanly, and a health check that alerts me when the portal login or watcher breaks. Portal credentials belong in a secrets vault, not in prompts or logs.

The guardrails matter more than the automation. Rate limit registrations. Redact plates in long-term logs. Delete photos after a short window. Keep screenshots only when a run fails. Require manual approval for low-confidence OCR, unknown senders, paid actions, or anything that changes account settings.

This is not an enterprise platform. It is a home project. But the lesson is the same as larger agent systems: the model is only one piece. The product is the loop around it, the permissions it respects, and the way it behaves when the world is messy.