You Can Just Do Things

Your household is running a back office on unpaid overtime. The inbox is the ticket queue. The kitchen counter is the document database. Somewhere, a school portal is demanding a password reset for the privilege of taking your money. You are the integration layer.

You can build something about that. Pick a recurring nuisance. Give an agent a precise job, a small set of inputs, and a place to put the result. Run it. Inspect what happened. Change the brief. The distance between an idea and a working prototype is small enough to cross before the weekend disappears.

That is the useful meaning of you can just do things. Stop treating your own agency as a feature somebody else has to ship. You can become the person who wires the pieces together.

The kitchen is a perfectly good lab.

A household gives you an unusually direct feedback loop. You know who does the work. You can see the backlog. You feel the cost when a task goes sideways. A draft grocery order is either useful on Thursday afternoon or it is another thing to fix. There is very little room to hide behind an impressive presentation.

Start with work you have the authority to delegate, using information you have the right to use. Other people in the household get a say in how their messages, schedules, and records are handled. The small scale makes the conversation easier to have; it does not make their privacy disappear.

Then keep a friction log. Every time you spend ten minutes copying details between systems, hunting for a date, or rewriting the same email, make a mark. Record the frequency and the time. After a week, rank the list. Your first agent should come from the expensive repetition near the top.

The most punk thing you can do with a computer is make it answer to your actual life.

Give the machine a job description.

“Help me manage my life” leaves almost every important decision unspecified. Try this instead: “Read the school notices I put in this folder. Extract event dates, deadlines, and required actions. Link every entry to its source. Draft a weekly summary. Flag conflicts. Do not change the calendar.”

That brief has edges. You can test whether the agent crossed them. You can see whether a missing date produced a question or a confident invention. You can decide which failure matters before it becomes your Tuesday.

Separate roles when their permissions or standards differ. An inbox triager needs a different view of the household from a statement reviewer. A contractor-comparison role needs the project scope and the bids; it has no use for your family’s medical records. The separation makes it easier to understand what each agent can reach.

A role can be a saved brief and a repeatable process. It can become a scheduled script with a model call and a review queue. You do not have to build an elaborate multi-agent framework to earn the right to automate one annoying job. Start with the smallest arrangement that you can inspect.

Build for the boring victories.

Consider a procurement agent for a home project. Give it a written scope and the quotes you have received. Ask for a comparison of included work, exclusions, materials, dates, and payment terms. Require a source reference for each entry. Ask it to list the questions that remain unanswered.

The deliverable is a table you can use to choose what to ask next. A lower number may cover less work. A confident-looking schedule may depend on materials nobody has checked. The agent should make those differences easier to see. You still choose the contractor and agree the terms.

Or take the subscription pile. Supply a redacted transaction export and a list of services you believe you have. Ask for possible duplicates, unfamiliar recurring charges, and price changes, each linked to the underlying entries. Treat the output as a review list. A merchant-name mismatch is something to investigate; the model has not magically established fraud.

These are candidate workflows, not promises of a specific saving. Measure the real result: time spent before, time spent reviewing now, correction work, software cost, and failures. A task that moves thirty minutes of typing into forty minutes of supervision has failed its audition. Fire the workflow or fix the brief.

Keep the commit button.

For a first household deployment, use a simple rule: the agent drafts; the human commits. It can assemble the cart, prepare the reply, or compare the bookings. You approve the purchase, send the message, or make the reservation.

Build that boundary into the tools. A drafts-only email role should have a way to create drafts and no way to send them. A comparison role should be able to read the quotes without possessing payment authority. OWASP’s guidance on excessive agency recommends limiting functions and permissions to the task and requiring human approval for consequential actions.

“Are you sure?” is a weak review screen if it hides the actual consequence. Show the proposed recipient, the complete message, the amount, the selected item, or the changed record. Approval should attach to a specific action. If the details change, the approval should expire.

That discipline is part of the craft. The fun is building a machine that reliably does what you intended. A system that improvises commitments on your behalf is a terrible housemate.

Your context is the interesting part.

The first useful improvement is often a better record. Which vendor serviced the boiler? What did the contractor exclude? Which appointment was moved? Why did you reject the other quote? Write the answers down with their dates and sources.

A model can work from that record the next time the question comes around. This is the same practical idea behind an LLM knowledge base: give the system access to the relevant context, in a form it can retrieve and you can check.

Keep the record selective. A grocery role needs preferences and a pantry list. It does not need every private document the household has ever produced. Decide where the information lives, who can access it, and how to remove it. An agent’s apparent helpfulness is a poor reason to give it everything.

Expect to become the maintenance department.

A portal changes. A credential expires. A document arrives in a new format. The workflow that worked last month now returns nothing, and nothing looks suspiciously like success if you never check.

Give each run a visible result: completed, needs review, or failed. Keep a small set of known examples. Include missing information, conflicting dates, duplicate documents, and a request outside the role’s scope. Re-run those examples when the workflow changes. This is a small, practical evaluation suite.

Budget for maintenance in the same ledger as the savings. You are allowed to retire a role that creates more work than it removes. You are also allowed to keep a small, unglamorous script that does one thing beautifully. A working system owes you utility.

Four weeks. One useful system.

Then take the judgment to work.

After a few weeks, you will ask better questions. What is the agent allowed to do? Where did this answer come from? What happens when the source is missing? Who notices the failed run? Can we undo the action? You will ask them because you have watched the answers matter.

That experience travels. Bring the habits into work through the organization’s approved process, with the right owners and access controls. A household experiment gives you something concrete to contribute: a tested way to scope work, inspect outputs, and keep people responsible.

There is a peculiar freedom in realizing that a recurring irritation can become a small engineering project. You can name it. You can take it apart. You can give the repetitive pieces to a machine and keep the decisions that deserve your attention.

Pick one thing. Build the first version. Make it show its work.

If the next thing on your list belongs to a business, Sovereign Action can help turn it into a first workflow: defined scope, explicit permissions, agreed tests, and a human owner. Start with a free twenty-minute conversation.