Phinehas Adams

Automation & AI tools

Less copying.
Fewer loose ends.

I build tools for the information you keep moving by hand: requests, records, orders, and the follow-up around them.

We start with one task, work out what should happen, and keep a person involved where judgment matters.

Talk about a task

Useful places to start

Follow the information.

Here are three examples of work we can automate. We start with the task you repeat and the tools you already use.

  1. Requests into something you can review.

    Read a customer request, pull out the useful details, check them against an available source, and prepare a reply or record for someone to approve.

    An email or form comes in

    A prepared draft, with gaps marked

  2. Forms into tidy records.

    Validate required fields, format the values, and place them in a spreadsheet or business tool. Agree how repeats and incomplete submissions should be handled.

    Someone submits information

    A consistent entry in the right place

  3. Tools that share the right information.

    Connect a shop, inventory system, or other tool where its interfaces allow it. Define which system owns each field, how updates are matched, and what happens when values disagree.

    A product or record changes

    An agreed update in a connected tool

Choose the right tool for the step

Rules where they fit.
AI where it helps.

Fixed instructions

Use ordinary code for things with a defined answer.

  • Check that required fields are present.
  • Copy agreed values between records.
  • Apply a known calculation or formatting rule.
  • Match an update to the correct existing item.

Reading and drafting

Use AI where the input is varied language, with checks around the result.

  • Suggest fields from a written request.
  • Sort or summarise incoming messages.
  • Prepare a reply using the available facts.
  • Flag unclear details for a person to check.

The review point is part of the build. Missing prices, conflicting details, and important decisions need a defined check before the next action.

See how I think through a task.

Fictional example

“Can you send 12 of the same filters we bought last time? We’ve moved shops. What’s the total?”
12

Quantity is clear.

The model, address, and price still need checking.

This walkthrough runs in your browser with fixed example rules. It shows the reasoning and review step; it is not connected to an inbox, shop, or AI service.

The practical details

Know what happens
at every step.

We work through the ordinary task and the awkward cases: a missing detail, a duplicate request, or a tool that is unavailable.

Where the information comes from
We identify the form, inbox, file, or tool that starts the task, then use sample records to define the fields and the source of truth. Missing information gets a visible path back to a person.
What needs approval
We agree which actions can run from fixed rules and which need a review step. Replies, proposed changes, and anything with a meaningful consequence can be held for approval before it leaves the workflow.
What happens when it cannot finish
An unavailable tool, an incomplete record, or a conflicting value needs a defined response. We agree how to flag the item, where the error is recorded, and who picks it up. Duplicate handling and retries are part of that design.
What access it needs
I check the connections your tools support and the permissions the task requires. Credentials belong in the agreed secure setup; we decide account ownership and who can maintain or disable the connection.

How we work

One task.
A working path.

I build the workflow myself. You bring the real process and check that the result is useful.

Need a website too?

  1. Show me one task.

    Walk me through what you do now, including the awkward exceptions. A few example requests or records help us see what is consistent and what needs a decision.

  2. Draw the boundaries.

    I define the input, the actions, the checks, and the review point with you. We agree the tools involved, access, scope, cost, and timing before implementation.

  3. Build and test the full path.

    I build the workflow and check it with representative examples, including missing details, duplicates, and failed connections. You review the outputs and how the exceptions are handled.

  4. Run it with a clear handover.

    We agree how it is switched on, monitored, paused, and maintained. I explain the setup and its limits, and hand over the relevant access and instructions.

Before we start

A few useful
answers.

Does every automation need AI?

No. Moving values between tools, checking required fields, and applying a fixed calculation usually belong to ordinary code or rules. AI is useful when a task involves interpreting varied text or preparing a draft, and its output still needs appropriate checks.

Can you use the tools I already have?

That is the starting point. I check the tools and the connections they support, such as an API or a structured import/export. Some actions may need extra permissions or a different approach. We confirm that before including them in the build.

Will it send messages or change records by itself?

Only where that action is part of the agreed workflow. We define what can run automatically and what should wait for a person. A prepared reply can stay as a draft, and a proposed update can wait for review rather than being applied immediately.

What do you need from me to get started?

One repeated task, the tools involved, and a few examples of the information moving through it. You can describe it in plain language. Use anonymised or made-up examples for an initial conversation; we agree the access needed for the actual build later.

What happens if the workflow needs changing later?

The handover covers how it works, the tools it depends on, and what can be changed safely. We discuss who will maintain it and whether you need further support. Changes to a connected tool or to the task itself may need the workflow to be updated and checked again.

What do you keep
doing by hand?

Tell me the task, the tools you use, and where it gets stuck. Plain language is fine.

Talk about a task