Behind the scenes at IZZY: four AI automations already running in real operations

Some of the most useful AI has no chat window.

It receives a registration, updates a profile, waits for a status to change, gathers information, prepares a dossier, transforms an approved article or flags a shift in Search Console. The user does not see a model. They see the work move forward and the right person step in at the right moment.

This is the less visible layer we build at IZZY. Not demos that answer three prepared questions, but workflows connected to the company’s tools, rules and responsibilities.

Here are four systems used in real operations. Havana Club is named; the other client contexts are deliberately anonymised. We explain the useful mechanics, the design decisions and the limits. We do not publish identities, confidential data or performance figures we cannot substantiate.

Answer in 60 seconds

The four systems solve very different operating problems:

1. User activation and follow-up: n8n connects a waitlist, a Notion CRM, prioritisation rules, reminders and profiles across several applications.
2. Opportunity screening: a workflow assigns collection, OCR, structuring and evaluation to specialised models, then produces a first classification from a confidential list of questions before human review.
3. Editorial production: a publication framework turns an editor-prepared article into a complete publishing package, including structure, media and metadata.
4. Post-migration Search Console monitoring: every week, an automated chain compares the latest snapshot with the full history, produces the report and sends it to an SEO specialist for approval.

The common factor is not a particular model. It is an operating architecture:

event → reliable state → rules → interpretation when needed → action → trace → exception

AI is used where the work requires interpretation, summarisation or comparison. Deterministic rules remain the better choice when a simple condition is enough. A person remains responsible for the criteria, exceptions and decisions that commit the business.

In this article

1. Start with the work that gets lost between tools
2. Turn a waitlist into an activation journey
3. Automate collection without automating the verdict
4. Automate the publishing workshop, not the editorial position
5. Turn Search Console into a continuous observation system
6. Four systems, one operating architecture
7. How to choose the first workflow to automate

1. Start with the work that gets lost between tools

A company rarely describes its problem as: “We need an orchestrated workflow with persistent state and an LLM layer.”

It is more likely to describe one of these symptoms:

• people are sitting in Notion with no reliable state for the next follow-up;
• too much time goes into gathering information before dossiers can be compared;
• an approved article is still far from being live;
• Search Console data exists, but the report arrives too late to guide the next decision.

The problem sits in the handovers: between a form and the CRM, a public source and an evaluation framework, an editorial document and the website, or a metric and the action it deserves.

That is why we do not start by asking which model to use. We first map six elements:

Sometimes the right answer is an integration and a few rules. Adding an LLM would make it neither more reliable nor more useful. In other cases, the volume and variety of the information justify an interpretation layer. Our job is to put that layer in the right place, then make the rest observable.

2. Turn a waitlist into an activation journey

A registration is an event. It is not yet an active relationship.

In one workflow we operate, the journey was automated from day one. People join a queue through links shared in a newsletter, live streams and WhatsApp or Telegram groups. They then appear in Notion, used here as an operational CRM.

The aim was not to replace an earlier manual task. The system needed to connect prospect and lead records, payment information, newsletter subscriptions, community accounts and product-website accounts from the outset. In this implementation, a person is considered activated after completing the journey, answering the required questions and buying the product.

The automated journey

The workflow moves through five stages.

1. Create the record

When someone registers, their record enters Notion. Information they have chosen to provide becomes structured fields that the next stage of the journey can use.

2. Prepare the processing priority

n8n gathers the data needed for the next step and applies the criteria defined for the process. The ranking is not a general judgement about the person. It organises the work according to explicit business rules that the journey owner must be able to explain and change.

3. Drive reminders from state

The system does not send the same sequence to everyone regardless of what happens. It checks whether the expected action has been completed. While the state remains open, it can schedule the next reminder according to the journey rules. Once the action is complete, the reminder branch stops.

4. Synchronise profiles

The Notion record does not exist alone. Other services hold their own profiles or statuses. n8n propagates the required changes so that a person does not appear as “needs follow-up” in one tool and “activated” in another.

5. Keep a human path for manual changes

The confirmed exception path is a manual state change, for example when a refund is required. Other incidents and recovery mechanisms were not documented for this article, so we do not claim either that a particular failure is common or that the system has never failed.

The system can be summarised as:

touchpoint → registration → CRM record → structured data → priority → conditional reminder → answers → purchase → synchronisation

What the automation should not decide alone

The workflow runs the journey. It does not define whether the journey is legitimate.

A person remains responsible for:

• the action the user is actually being asked to take;
• the criteria used to organise records;
• the frequency and stopping conditions of reminders;
• the data each service is allowed to hold; and
• the situations in which human contact should replace automation.

Where personal data is involved, access, retention and purpose must be defined for the actual process. Our guide to managing AI agent permissions explains how to connect an identity and access grant to a mission, owner and revocation path.

The value of this system is not “sending more messages”. It is giving the journey a usable state: knowing who is waiting for what, which event stops the automation and where an exception requires a decision.

Part 2 of this guide, This funnel was never manual, describes the journey in detail.

3. Automate collection without automating the verdict

The second system is used in a venture-capital process that screens international technology startups. The organisation, geography, investment strategy and exact evaluation criteria remain anonymised.

The automated question is not “Should we invest?” It is narrower: “Does this dossier deserve the time required for deeper human analysis?”

The manual work involved gathering information from scattered sources, analysing it and checking each item against the same criteria. The workflow turns those waves of information into comparable dossiers while preserving the difference between public data, a claim supplied by the startup, model interpretation and the human decision.

First stage: enrich a minimal record

The process begins with a structured record containing the initial information available. An automation then gathers signals from permitted public sources, primarily X and the other public presences relevant to the agreed scope.

Each useful item enters a field designed for that purpose. Its provenance must remain identifiable. A promotional statement on a website does not become an independently established fact because it has been copied into the CRM.

Second stage: integrate received documents

When a project later provides more complete information, the documents are analysed against a structure defined in advance. The system extracts the elements that correspond to the expected criteria and adds them to the record without erasing the signals already collected.

That separation matters. It shows:

• what came from a public source;
• what the project claims about itself;
• what is still missing;
• what appears to conflict; and
• what is already an interpretation.

Third stage: give each model a specific job

In the current setup, models from different providers are selected for their fit with a specific task. They do not produce competing analyses: they complement one another within the same chain.

• one model analyses signals from X;
• another processes the other public sources;
• a specialised model handles OCR for supplied documents, including the pitch deck; and
• a final model applies the evaluation framework to the structured dossier and prepares the classification.

Changing the model does not turn a claim into evidence. Provenance, original documents and unknowns must remain visible throughout the chain.

Fourth stage: answer a defined list of questions before the human handover

The exact framework is confidential. It contains a list of questions that the system must answer with “yes”, “no” or “possible”. A question the dossier cannot answer is recorded as missing rather than forced into one of the three. Taken together, the responses produce an initial classification using the same three categories.

This classification is neither an investment recommendation nor due diligence. It is used to decide whether the dossier deserves deeper human analysis. When the answer is positive, or uncertain enough to justify investigation, a person takes over.

The useful chain is therefore:

initial profile → public sources → pitch-deck OCR → structured dossier → bounded answers → initial classification → human analysis

The automation brings discipline to screening. It reduces the part of the work spent finding, moving and reformatting information. It does not turn an internal framework into a universal truth or make the investment decision.

Part 3, From days to minutes, goes through the pre-screening workflow stage by stage.

4. Automate the publishing workshop, not the editorial position

An article can be approved in substance and still be a long way from publication.

The team still needs to apply the website structure, process images, check filenames, produce metadata, choose a category, prepare the expected formats and confirm that the final package is complete. Repeated for every article, this becomes a production tax. Done in a hurry, it creates omissions that improve neither the content nor the reader’s experience.

The IZZY Content Publication Framework automates this layer.

It starts after the editorial decision

The system does not receive the vague instruction “write something about AI”. It starts from an article, analysis or research piece prepared by an editor. The input format is not fixed, but the essential blocks - introduction, body, conclusion, verdict or their equivalent - must be present.

The team has already defined:

• the subject;
• the reader;
• the angle;
• the sources and evidence; and
• the conclusion the brand can defend.

The framework knows several content contracts: news, analysis, research articles and other formats defined in the editorial system. Each contract specifies the expected structure and the elements required for publication.

It turns content into a publishing package

Depending on the selected contract, the system can:

1. convert the article into the technical structure expected by the website;
2. normalise fields and navigation elements;
3. convert images to WebP and fit them to their placement;
4. propose missing metadata, particularly alt text;
5. check for required files and fields; and
6. produce and publish the content in the format expected by the website.

An LLM can propose alt text based on what is actually visible in an image. It should not invent a product, person or context that is absent. More broadly, the framework does not silently fill a required part: validation fails when the necessary information is missing.

Human control comes before automatic mode

The current journey runs through a web interface. The person importing the content moves through several validation stages and accepts or rejects the proposed changes. The system does not become autonomous until those decisions have been made.

Once everything has been approved, processing and publishing continue automatically. Every content state is versioned, which creates a rollback path instead of silently overwriting the last reliable version.

The chain becomes:

editorial import → required-block check → transformation → WebP media fitted to placement → proposed changes → human validation → automated processing and publishing → versioned state

What the framework does not replace

It does not decide why a subject deserves publication. It does not own the experience being described. It does not turn a weak source into evidence. It does not take responsibility for a claim.

The intended gain comes from repeatable production, not the removal of the editor. That is why we separate automation from authority before anything reaches production.

Part 4, The article is approved. Why is it still not published?, covers the framework end to end.

5. Turn Search Console into a continuous observation system

The website of Havana Club had just been rebuilt. Its structure had changed. The need was not to replace an old manual report - none existed - but to establish a regular view of organic recovery from the moment of migration.

The Search Console workflow built by IZZY runs once a week. It retrieves the latest snapshot, compares it with every previous snapshot, produces the charts and generates a report from the rules in the reporting brief. An LLM layer carries out the analysis and drafting automatically.

Before the client receives it, an SEO specialist reads the document, simplifies it when necessary and approves it. In most cases, this review takes 15 to 25 minutes.

Collection follows a stable contract

Every week, the system queries the authorised data and preserves the dimensions required for the report: dates, pages, queries or the segments selected for the scope.

Google’s Search Analytics API can query performance using defined filters and dimensions, returning metrics including clicks, impressions, CTR and average position. Google also states that the API does not guarantee every data row and prioritises top rows, while recent data may remain incomplete. A serious automation must preserve those limits instead of turning a partial extraction into certainty. See the official documentation.

History makes changes comparable

The system archives the data and its methodological context: property, period, dimensions, filters and data state. The current snapshot is compared with the full history, not only the previous week. The report can therefore show where the website sits in its recovery since migration.

The report has a stable core

Other sections can appear when the data warrants them. The first weakness encountered was not a false signal: some reports supplied too much information and explained it too densely. The system had to learn to prioritise and simplify. In automated reporting, overload is a failure mode too.

“100% automated” does not mean “100% certain”

Collection, full-history comparison, visualisation, analysis and draft production run automatically. That does not make every explanation correct, and it does not trigger client delivery without control.

An automated recommendation can flag a page for investigation. It should not silently rewrite the website or attribute a change to the first plausible story. The SEO specialist remains responsible for approval and the action that follows. The 15-to-25-minute figure describes the usual review, not a measured before-and-after saving.

The complete chain is:

weekly extraction → full history → recovery trends → LLM report → simplification → SEO approval → client delivery

Part 5, After a site migration, details the reporting workflow and the limits of Search Console data.

6. Four systems, one operating architecture

These four stories do not share the same user, data or consequence. They share a design discipline.

Three rules summarise our approach.

Rules before models

If a condition can be expressed clearly, keep it deterministic. An LLM does not need to decide whether a required field is empty or a date has passed. Our AI pilot-to-production checklist uses the same human, deterministic, assistant and agent distinction to decide which mechanism a workflow needs.

State before prompts

A good prompt cannot compensate for a system that does not know what has already happened. Records, statuses, versions and sources must survive one execution and remain available for review.

Exceptions before scale

The question is not only “What does the workflow do when it succeeds?” It is “What does the team see when data is missing, two tools disagree or a provider changes?”

That is the difference between an automation that looks impressive in a demo and a system the business can actually operate.

7. How to choose the first workflow to automate

Do not begin with the most visible process. Begin with one whose boundary can be understood and measured.

Ask seven questions:

1. Does the work recur often enough to justify a system?
2. Does it cross several tools, teams or states?
3. Can the reliable input and expected result be named?
4. Can simple rules be separated from interpretation?
5. Can an error be detected, stopped and recovered?
6. Does a person own the process and its exceptions?
7. Is there a baseline for comparing time, rework, failures or quality?

The answer should not always be “build”.

Conclusion: an operational AI system is one the team can explain

A useful automation is not measured by the number of models, nodes or tools connected. It is recognised through simpler questions.

Does the team know what starts the work? Where is the reliable state? Which rule applies? What is the model actually interpreting? What happens when the result is missing or wrong? Who can stop the system?

Across the four systems described here, AI does not erase the process. It takes on a precise part of the movement: preparing, matching, structuring, comparing or flagging. The decision that commits the business remains assigned.

Frequently asked questions

Sources and limitations

• The four operating descriptions come from IZZY’s own project knowledge, recorded on 25 August 2026 and extended for the Search Console workflow on 7 September 2026. Havana Club is named; the other clients and any identifying implementation details are deliberately omitted.
• No claim is made about time saved, activation rate, decision quality, publishing volume, traffic, leads or revenue: no attributable before-and-after baseline was supplied. The 15-to-25-minute Search Console figure describes the usual review time, not a measured saving.
• Google Search Console API and Search Analytics query method: the API provides programmatic access to performance data, with row and freshness limits that must remain visible in interpretation.
• Architecture, providers, models, criteria, access and retention policies must be verified for each deployment. This article is not a technical audit or an assessment of security, compliance or performance.