Two Internships, Two Very Different Kinds of "Automation"
People use the word "automation" as if it means one thing. After working as an AI Intern at Draskenlabs and then as an RPA Developer Intern at Avent IQ, I can tell you it doesn't. At Draskenlabs, automation meant building an n8n workflow that used AI to make decisions inside a process. At Avent IQ, automation means building RPA bots with Automation Anywhere that execute the exact same steps a human would follow, every time, without deviation.
They look similar from the outside — both replace manual work — but they solve different problems, fail in different ways, and require different mindsets to build well. Here's what actually distinguishes them, based on the work I do, not abstract theory.
What RPA Actually Looks Like Day-to-Day
At Avent IQ, my work is:
- Developing and maintaining RPA bots for business process automation using Automation Anywhere
- Monitoring bot execution and validating workflows in production
- Testing bots, debugging failures, and fixing them when something breaks
- Writing Process Definition Documents (PDDs) that describe the exact steps a bot follows
RPA bots are rule-based. A bot doesn't "decide" anything — it follows a scripted sequence: click this field, read this value, if the value matches condition X do Y, otherwise do Z. That rigidity is a feature, not a limitation. If a process is well-defined — data entry, extracting values from structured documents, reconciling data between two systems, form submission — an RPA bot will do it exactly the same way ten thousand times without drifting, without needing a prompt, and without incurring an API cost per execution.
The tradeoff is fragility to unstructured change. If a website changes its layout, if a file naming convention shifts, if an input field that used to always be populated shows up empty — the bot doesn't reason about it, it just fails. That's why so much of real RPA work isn't "building the bot," it's monitoring, testing, and debugging it in production, and writing PDDs precisely so that when something breaks, there's a clear reference for what the correct behavior is supposed to be.
A Simplified View of RPA Bot Logic
Automation Anywhere bots are built visually, but the underlying logic maps to something like this pseudocode:
IF invoice_field.status == "unprocessed":
read invoice_data FROM shared_drive
validate invoice_data AGAINST schema
IF validation.passed:
write invoice_data TO ERP_system
mark invoice_field.status = "processed"
ELSE:
move invoice_data TO exceptions_folder
notify process_owner
Every branch is explicit. There's no ambiguity in what the bot will do — which is exactly why it's auditable, and exactly why it can't handle a case nobody anticipated.
What AI-Driven Automation Actually Looks Like
At Draskenlabs, the automation I built with n8n was a different animal. Instead of scripting exact steps, I was wiring together a workflow where an LLM node made a judgment call — classifying input, generating text, deciding which branch to take based on meaning rather than an exact match.
A comparable n8n node chain looks like this:
{
"nodes": [
{ "name": "Incoming Request", "type": "n8n-nodes-base.webhook" },
{ "name": "Classify Intent (LLM)", "type": "n8n-nodes-base.httpRequest" },
{ "name": "IF: Needs Human Review", "type": "n8n-nodes-base.if" },
{ "name": "Generate Response (LLM)", "type": "n8n-nodes-base.httpRequest" },
{ "name": "Update CRM", "type": "n8n-nodes-base.httpRequest" }
]
}
The classification node doesn't check if field == "X" — it sends the input to an LLM with a prompt like:
Classify the following customer message into one of: [billing_issue,
feature_request, complaint, general_inquiry]. Respond with only the
category label.
This is powerful precisely where RPA is weak: unstructured input, natural language, and cases that don't map cleanly to a fixed rule. But it introduces real weaknesses of its own — outputs are probabilistic, so you need guardrails (constrained prompts, output validation, fallback branches) that a deterministic RPA bot never needs. And every LLM call has a cost and a latency, unlike a rule check that's instantaneous and free.
Side-by-Side: Where Each One Actually Fits
| | RPA (Automation Anywhere) | AI Automation (n8n + LLMs) | |---|---|---| | Best for | Structured, repetitive, rule-based tasks | Unstructured input, judgment calls, generation | | Failure mode | Breaks silently on unexpected input | Produces a plausible but wrong output | | Auditability | High — every step is explicit (PDD) | Lower — reasoning is inside the model | | Cost per run | Fixed (bot license/runtime) | Variable (API calls per execution) | | Change tolerance | Brittle to UI/format changes | More tolerant of phrasing/format variance | | Example from my work | Reading invoice data into an ERP system | Classifying a CRM message and drafting a reply |
Why They're Not Actually Competitors
The mistake I see people make is treating this as "which one should I learn." In practice, they're complementary layers of the same pipeline. A process almost always has a structured part and a judgment part. Take the RPA-style pipeline I built for automated image filtering with face recognition (input → processing → decision-making → output) — the input/output handling is rule-based and deterministic, but the "decision-making" step (does this face match a reference profile) needs something closer to a model's judgment, not a hardcoded rule.
The same logic applies at the workflow level: an n8n workflow can call out to a rule-based bot for the deterministic parts of a process, and a rule-based bot's PDD can define exactly where in a pipeline an AI decision point needs to sit. The best automation architecture I've seen (and tried to build) uses RPA for the parts of a process that are genuinely fixed, and reserves LLM-driven steps for the parts that require actual judgment — not because it's trendy to add AI everywhere, but because using an LLM to do a job a simple rule could do is slower, more expensive, and less predictable than the rule.
Advice If You're Choosing Between Them
If you're a CS student deciding what to learn first: learn RPA fundamentals before AI automation, not after. Rule-based automation forces you to think precisely about process steps, edge cases, and failure handling — skills that transfer directly into designing good guardrails around an LLM later. Going straight to "wire an LLM into everything" without that discipline tends to produce workflows that look impressive in a demo and fall apart the first time an edge case shows up in production.
Get in Touch
If you're working on RPA, n8n, or trying to figure out where AI actually belongs in your automation stack, I'd enjoy comparing notes. Reach me at rishabnishad22@gmail.com, on WhatsApp, or via my contact page.