From Spotted Work to Executable Automation

Most automation tools begin with the same assumption:

Someone already knows what should be automated.

You open a blank canvas, choose a trigger, connect a few systems and build the workflow.

That is useful. But after years of operating businesses and now building AI systems, I think there is a layer missing before the canvas.

The hard problem inside a company is often not how to automate a process.

It is noticing that the process exists at all.

Companies do not have processes. They have repeated behavior.

A process diagram is usually written after a process has already stabilized.

Real work looks different.

Someone receives an email. They copy something into Monday. They open another system. They check a customer. They ask a colleague a question. They generate a document. Then they move a status and repeat the same sequence tomorrow.

Nobody calls it an automation candidate.

It is simply “how we do this.”

That is the idea behind a system I am currently building called UniProWorks.

The concept is deliberately simple:

OBSERVE WORK
   ↓
SPOT REPETITION
   ↓
MODEL THE PROCESS
   ↓
PROPOSE AUTOMATION
   ↓
GENERATE AN EXECUTABLE IMPLEMENTATION
   ↓
VERIFY
   ↓
HUMAN APPROVAL
   ↓
RUN + MEASURE

The interesting part is not generating workflow JSON.

The interesting part is deciding whether a workflow should exist.

“Spotted” is a product primitive

I want the system to be able to say something like:

This sequence occurred seven times. Most steps are deterministic. Two steps require language interpretation. One external action should remain human-approved. Automation opportunity: high.

That is much more useful than “Ask AI to build an automation.”

It gives the AI a constrained job:

• recognize repeated structure,
• separate deterministic work from ambiguous work,
• identify inputs and outputs,
• expose dependencies,
• estimate where human authority is still necessary,
• propose a testable implementation.

Only after that should generation happen.

n8n is a perfect execution target

One execution target I am experimenting with is n8n.

Once UniProWorks has converted observed work into a structured process contract, generating an n8n workflow becomes a compilation problem rather than a prompting problem.

For example:

Trigger: Qualified lead created
Inputs: company, email, website, source
Steps:
1. Enrich company
2. Classify lead
3. Draft personalized outreach
4. Store result
5. Request approval
6. Send after approval

That contract can then compile into nodes, credentials, conditions, AI calls and human gates.

The generated workflow should initially be inactive.

The system should run test payloads, validate expected states and only then ask a human whether it can be activated.

This is the same principle I use in production AI systems elsewhere: AI can propose structure, but execution authority belongs to explicit constraints.

Why my operations background matters here

Before working full-time on AI systems, I spent years building and operating logistics businesses.

In logistics, process discovery is not academic. If the same failure happens every day, margin disappears. If the same manual reconciliation is performed thousands of times, somebody eventually builds a system around it.

The useful question was rarely:

What software feature should we build?

It was:

What is everybody repeatedly doing because the system does not yet understand the work?

AI makes that question far more interesting because software can finally interpret a messy layer of work that was previously invisible to deterministic automation.

Automation should be discovered, not requested

I think the future automation stack will have at least three layers:

1. Observation - understand what actually happens.
2. Process intelligence - identify repeatable structure, risk and opportunity.
3. Execution - n8n, APIs, workers, agents, human tasks and deterministic services.

Most of today’s tools are concentrated in layer three.

I am interested in building the layer above it.

Not an AI that blindly creates workflows.

A system that can explain why this workflow should exist, what authority it should have, how it should be tested, and whether it actually improved the work after deployment.