How to Build an AI Automation

How to Build an AI Automation

Building an AI automation means turning a repeated task into a clear process that uses an AI model where interpretation or generation is needed.

A reliable automation is not created by connecting a model to a task and hoping for a useful result. You need to define the outcome, understand the current process, choose the input, divide the work into steps, select a suitable model, control the output, handle failures, and decide where a person should review the result.

A simple AI automation may look like:

Input → AI Task → Reviewable Output

A more complete process may include:

Trigger
→ Validate Input
→ AI Classification
→ Apply Rules
→ Use a Tool
→ Human Review
→ Save the Result

Begin with the smallest version that solves a real problem. Add complexity only when testing shows that another step is necessary.

Start with one repeated task

Choose a task that you already understand.

A good first automation is usually:

• performed regularly;
• completed in a similar way each time;
• based on information you can access;
• expected to produce a clear result;
• easy to check; and
• low risk when a correction is needed.

Suitable starting tasks include:

• summarising meeting notes;
• extracting action items;
• classifying customer messages;
• preparing a report draft;
• organising research findings; or
• converting unstructured text into defined fields.

Avoid starting with an entire department, a vague goal, or a process that depends on undocumented judgement.

Instead of:

Automate customer support.

Choose a narrower task:

Read an incoming customer message, assign one approved category, identify
missing account information, and prepare a draft reply for review.

The narrower outcome is easier to build, test, and improve.

Define the outcome before choosing a tool

Write down what the automation should produce.

A useful outcome describes:

• the task;
• the input;
• the expected result;
• the intended user;
• the required format; and
• the level of review.

For example:

Given a set of meeting notes, return a short summary, confirmed
decisions, and a table of actions with Owner, Task, and Deadline.

Use "Not provided" for missing information.
Return the result to a person for review.

Map the current manual process

Before automating the task, describe how it is completed today.

Record:

1. what starts the task;
2. which information is collected;
3. what decisions are made;
4. which systems or tools are used;
5. what result is produced;
6. who checks the result; and
7. what happens when something is missing.

This often reveals that the task contains several different types of work.

For example, preparing a weekly project report may involve collecting updates, removing duplicate information, extracting progress and blockers, checking for missing owners, writing a summary, sending the draft to a manager, and saving the approved version.

Not every step needs AI.

Collection, exact checks, routing, calculations, and saving may be handled by normal workflow logic. AI is useful for interpreting varied language and preparing the summary.

Separate AI tasks from fixed rules

Use AI where the process requires understanding or generation.

Examples include:

• interpreting a message;
• classifying content by meaning;
• extracting details from varied text;
• comparing written sources;
• summarising a document; and
• drafting a response.

Use deterministic steps where the answer can be expressed exactly.

Examples include:

• checking whether a field is empty;
• comparing a number with a threshold;
• validating a date format;
• routing an approved category;
• calculating a total;
• naming a file; and
• running at a selected time.

Suppose an AI model extracts an invoice total from differently formatted text. A normal calculation should then apply tax, and a fixed condition should decide whether the value exceeds an approval threshold.

Do not ask the model to perform exact work that a normal operation can complete more predictably.

Define the input

Decide what information the workflow will receive.

The input might be:

• text entered by a user;
• a document;
• a form response;
• a message;
• an image;
• a group of records;
• information returned by a tool; or
• content collected on a schedule.

Describe what valid input looks like.

Check:

• which fields are required;
• which formats are supported;
• how much information may be provided;
• whether the content may be sensitive;
• whether unrelated instructions may appear in the source; and
• what should happen when the input is empty or incomplete.

Use representative examples rather than one perfect sample.

If the automation processes customer messages, collect examples that are short, long, unclear, urgent, incomplete, and outside the expected categories.

Prepare only the information the model needs

Raw input may need preparation before it reaches the AI step.

Preparation can include:

• removing duplicate content;
• selecting relevant fields;
• dividing a long document into sections;
• converting information into a consistent structure;
• removing unnecessary personal details;
• adding approved background information; or
• rejecting an unsupported file.

Preserve important context, but send only what is needed for the defined outcome.

Give each AI step one clear responsibility

A large instruction that asks one model to classify, extract, compare, summarise, draft, and make a decision can be difficult to test.

Divide the process into focused steps when the results need separate review.

For example:

Customer Message
→ Classify Request
→ Extract Stated Details
→ Draft Reply
→ Return for Review

Each step has one understandable outcome.

Focused steps make it easier to identify where an error occurred, change one instruction, compare models for a specific task, validate intermediate output, and reuse a successful step later.

Do not divide a simple task unnecessarily. One AI step may be sufficient for a short summary or rewrite.

Write a testable AI instruction

An AI instruction should explain:

• what the model must do;
• which source it should use;
• what the result must include;
• how the result should be formatted; and
• what the model must avoid.

For example:

Read the customer message.

Return:
1. one category from Billing, Technical issue, Cancellation, or Other;
2. a one-sentence summary;
3. the account number if it is stated; and
4. missing information needed for the next step.

Use only the message.
If a detail is absent, write "Not provided."
Do not make promises or propose a final resolution.

This is more testable than:

Handle this customer request.

Use explicit category names and field names. Explain what should happen when the source does not contain an answer.

Choose a suitable AI model

There is no single best model for every automation.

Choose based on the actual step.

Consider:

• instruction-following quality;
• accuracy with the source;
• supported input types;
• context size;
• tool support;
• response speed;
• provider cost;
• privacy requirements; and
• local hardware requirements.

A fast model may be sufficient for simple classification. A more capable model may be useful for a long comparison or complex structured report.

A local model may be appropriate when you want model processing to remain on your computer or need to work without a cloud provider.

A cloud model may offer capabilities or input support that are not available from a suitable local model.

Test models with the same instruction and source information. Choose the model that meets the requirements of the task.

Define a structured output

Another workflow step needs a predictable result.

Instead of allowing an unrestricted paragraph, define fields such as:

Category:
Summary:
Account number:
Missing information:
Review required:

Structured output makes it easier to check required fields, apply conditions, route the result, save information consistently, and show missing values clearly.

Define the allowed values where possible.

For example, the category should be one of four approved labels rather than any description the model chooses.

Add validation after the AI step

Validation checks whether the result can be used safely by the next step.

It may confirm that:

• every required field is present;
• the selected category is allowed;
• a date uses the expected format;
• a number can be read correctly;
• the output is not empty;
• the result contains no unsupported value; or
• human review has been requested when required.

Keep exact validation outside the model where possible.

For example, do not ask another AI step whether the category is one of the allowed values. Use a fixed condition.

When validation fails, the workflow should stop, request corrected input, try a defined fallback, or send the result to a person.

Use conditions to control the path

Conditions let different results follow different routes.

A support workflow might use:

If Category is Billing → Billing Review
If Category is Technical issue → Technical Review
If Category is Cancellation → Retention Review
Otherwise → General Review

Conditions are also useful for missing information and errors.

For example:

If Account number is Not provided → Request More Information
Otherwise → Continue

Every branch should have a clear endpoint.

Include an Other, Unclear, or human-review path when an AI classification may not fit the expected categories.

Test every possible route, not only the most common one.

Add tools only when the process needs them

A tool allows the workflow to retrieve information or perform an action.

It may search an approved source, read a file, retrieve a record, write to a Journal, save a report, create an item, or use a connected service.

Review each tool before adding it.

Check:

• what information it receives;
• whether it reads or writes;
• which external service it uses;
• which credentials or settings it requires;
• what permissions it has;
• whether its action can be reversed; and
• how failure is reported.

Use the least access required for the task.

Prepare and review content before a consequential write action. A model should not receive permission to send, remove, approve, or publish something merely because it can draft it.

Decide where human review belongs

Human review should match the impact of the result.

A person may need to confirm extracted values, correct a classification, approve a draft, resolve conflicting information, handle an exception, confirm an external action, or make the final decision.

A low-risk internal summary may need periodic checking.

A workflow involving customers, payments, legal matters, healthcare, employment, security, access, or safety needs stronger controls.

Review does not have to interrupt every normal result. You can route unusual, incomplete, or high-impact cases to a person while allowing routine, reversible steps to continue.

Make the status visible. A draft should be labelled as a draft, and an unverified result should not appear final.

Design the failure path

A reliable automation explains what happens when a step does not succeed.

Plan for:

• missing input;
• unsupported files;
• unavailable models;
• provider timeouts;
• invalid output formats;
• tool errors;
• denied permissions;
• incomplete actions; and
• uncertain results.

Depending on the task, the workflow may stop with a clear message, request better input, retry a temporary failure, use another approved model, return a partial result with a warning, or send the case for human review.

Be careful with automatic retries after write actions. Confirm whether the first action completed before repeating it, or the workflow may create duplicates.

Test the automation systematically

One successful run is not enough.

Test with:

• normal input;
• short input;
• long input;
• missing fields;
• conflicting information;
• unusual wording;
• unrelated content;
• unsupported formats;
• every decision path; and
• examples that should fail.

For each test, review whether the correct steps ran, the model followed the instruction, the output matches the source, required fields are present, missing information remains missing, conditions choose the correct path, tools receive the correct information, errors are visible, and the final result is useful.

Record repeated problems. Improve one weak step at a time and repeat the complete test set after a material change.

Measure whether the automation helps

An automation is useful only when it improves the process.

Measure:

• time saved;
• output accuracy;
• review effort;
• failure rate;
• number of corrections;
• consistency;
• processing cost;
• model speed; and
• whether users understand the result.

Compare the automated result with a clear baseline. Review performance again when the model, instruction, source format, tool, or requirement changes.

Build an AI automation in Feluda

Feluda is a desktop application for building and running visual AI workflows.

A practical building process is:

1. connect a supported cloud or local AI provider;
2. test the task and instruction in Workbench;
3. open Studio;
4. add an Input block;
5. add the most suitable AI block;
6. configure the provider, model, and instruction;
7. connect the result to validation, another step, or an Output block;
8. save the workflow;
9. test it with several examples; and
10. run the saved version through RunFlows.

Feluda Studio includes focused blocks for common workflow purposes.

An LLM block can summarise, compare, analyse, or draft.

LLM Label can classify content into defined routes.

LLM Extract can return named fields from unstructured text.

Expression can apply fixed conditions and transformations without asking a model to make an exact decision.

Use the block that matches the task most directly.

Genes can add tools, prompts, flows, and resources. Review what a Gene or tool does before adding it to a workflow, especially when it connects to an external service.

Feluda can also use compatible local models. The complete process is only local when its tools, sources, and destinations also remain local.

Start with a three-block workflow

A useful first version is:

Input → LLM → Output

For example, create a workflow that receives notes and returns a summary.

Use an instruction such as:

Summarise the input in no more than five bullet points.

Include decisions, actions, owners, and deadlines.
If a detail is missing, write "Not provided."
Do not add information that is not in the input.

Test the flow with several examples.

After the simple version works, consider whether the task genuinely needs an extraction step, a classification route, a fixed condition, a tool, another model, an error output, a saved destination, or a schedule.

Add one change at a time.

Automate the trigger last

Manual runs are easier to observe and control during development.

Do not schedule or automatically trigger the workflow until:

• the expected input is defined;
• normal and difficult examples have been tested;
• every branch has been reviewed;
• failures return visible information;
• write actions have appropriate safeguards;
• the output can be checked; and
• someone is responsible for monitoring the process.

Run the saved workflow manually through RunFlows first.

After the results are dependable, a supported recurring workflow can be considered for Schedule Manager.

Scheduling does not make an unreliable process reliable. It only allows the same process to run without a person starting it each time.

Improve the workflow gradually

Begin with a result returned to a person.

Review several runs and identify the first step that produces an incorrect or unusable result.

Improve that step by clarifying the input, shortening unnecessary context, revising the instruction, choosing a more suitable model, defining stricter output fields, adding validation, changing a condition, limiting tool permissions, or adding a review route.

Avoid rebuilding the complete workflow whenever one result is poor.

Reliable AI automation usually comes from a series of small, tested improvements.

The goal is not to remove every human action. It is to let software handle repeatable work while people retain judgement, approval, and accountability where they matter.