From BA to Agentic Analyst: Rapid Prototyping and Token Costing with n8n
Years ago I modelled a university student admissions process by hand. This time I described one to n8n's AI assistant and watched it run. A first look at rapid prototyping, token costing and where a human still has to sign.
SupersededA newer, fuller build is in Structure at the edges, freedom in the middle.
Introduction
Around a decade ago I modelled a university admissions process for a client in Australia. It took workshops and specialist tooling, and the deliverable was a whole suite of process models that our webMethods team then built. Recently, with that work as inspiration, I gave n8n's new AI assistant (currently in preview) a brief for a simpler admissions flow and had it running in about two hours.
I wanted to see how far things have moved in that decade. I had heard a lot about n8n, and it was time to look for myself. This is a first-impressions piece, but what stayed with me was less the tool than what it means for the analyst using it. Rapid prototyping, token costs recorded per step and a business case you can build inside the workflow itself point to a different job: not a business analyst handing over a specification, but what I have started calling an Agentic Analyst.
The short version
n8n's AI assistant turned a one-line brief into a working admissions workflow in about two hours. Every AI step reports the tokens it used, so the cost case can rest on real numbers. You still need to be technical, and a person still has to own the decisions that change a life.
What I set out to build
The brief was the same admissions space, application through to enrolment. The original models, at every level, were drawn by hand in specialist tooling and reviewed in workshops before the build. The Level 3 view below is one model from that suite, included as an overview of the key stages.
And here is the after: a simpler admissions flow, inspired by that work rather than copied from it, stood up in n8n from a plain-language conversation with its AI assistant.
It is not a like-for-like rebuild, and it was never meant to be. But the contrast, a formal modelling exercise then and a described-and-running workflow now, is the whole story in two pictures.
I was not trying to ship a production system in an afternoon. I wanted to see how much of a working admissions flow I could stand up as a first test. It breaks into three stages:
Intake and understanding. Gather the applicant's details, whether they arrive by form, email, another workflow or even social media, then read their transcript.
Screening and decision. Match the application against the admission rules, then let a human make the call on anything that is not clear-cut.
Offer and enrolment. Make the offer, wait for the applicant's response, then register and confirm the accepted student.
Throughout, the flow keeps applicant records in n8n's built-in Data Table and notifies staff over Slack and applicants over Gmail at each meaningful step. It is deliberately a mix of deterministic rules, AI-assisted judgement and human sign-off, rather than a straight-through automation.
How the AI assistant handled it
I did not place a single node by hand to get going. I described the process in one line, a university admissions team from application through to enrolment, and rather than guessing, the assistant asked the shaping questions back: how applications arrive, where records should live, how people get notified, which stages to automate and how the decision should be made.
From those answers and a handful of follow-up prompts, about two hours later I had a working first cut: the form, the applicant emails (an acknowledgement carrying an application ID, then an offer that fired a trigger on acceptance), the Slack summaries for staff, a centralised rule set to screen against and the routing for clear passes, clear fails and everything in between. The AI steps that read and cross-checked the transcript slotted into the same flow.
For a first sitting with a tool I had only read about, that is a striking amount of working process for the effort.
Following one application through
The clearest way to show what it built is to follow a single application through it. The test applicant, Jordan Bennett, applies for a BSc in Computer Science. Click through the steps to see what happens at each one, and what the applicant or the admissions team sees.
The applicant fills in the n8n-hosted form: name, contact details, programme, highest qualification and grade, plus a personal statement. They upload their academic transcript as a PDF, and submitting triggers the workflow.
Run as a test, the accepted path goes green the whole way, from the form through to the enrolment confirmation. That completed run is the workflow shown at the top of this post.
What impressed me
My honest first reaction was, simply, wow.
Two things drove it.
The reach for so little input. Everything in the walkthrough above, the form, the live email and Slack integrations, the rules and the routing, came from a conversation rather than a build manual.
The build experience itself. It felt like a Figma for workflow design and build: fast, visual and forgiving, where you shape the thing in front of you rather than fight the tool. After years in and around process work, that immediacy is what struck me most.
Data and cost observability
One capability deserves its own mention: observability. n8n gives you step-by-step visibility into every node, the data going in and the data coming out, so you can see exactly what each step received and produced.
The part that caught my attention was cost. A business analyst has to put a benefit case behind a design, and the long-standing tool for that is activity-based costing, which assigns the cost of systems, people and materials to the activities that consume them, and from there to each product, service or process instance. In an agentic process, tokens become a new cost driver.
The execution log fits this neatly. Each test run records the tokens used, both the total for the whole workflow and the count for every AI step.
That changes when the costing happens. Token counts are not money on their own, but multiply them by the model's per-token price and you have the running cost of each AI step. Instead of estimating that spend in a spreadsheet after the fact, an analyst can watch it accumulate across the AI steps and tune the process for cost in real time, before the business case is even written.
The role shift: from Business Analyst to Agentic Analyst
The takeaway I keep coming back to is what this does to the analyst's job.
In traditional delivery models, business analysts are often expected to produce documents: requirements, process maps and specifications that someone else then builds. The Level 3 model earlier in this post is exactly that kind of artefact, precise and inert until a delivery team turns it into something real. Here, the same plain-language description of a process became the working process. The gap between describing it and running it collapsed.
That points to a role I would call the Agentic Analyst (AA): someone who understands the outcome, the boundaries, the rules and the exceptions, and turns them into something that runs. An analyst who can describe a process clearly and orchestrate the AI and human steps within it will be valuable, and soon.
You still need to be technical, for now
I would not oversell the assistant. To get a result you would trust, you still need to be technically minded.
Knowing what a good process looks like, how data should flow, where a human belongs in the loop and what an integration or a credential actually needs still matters, and the assistant assumes a fair bit of it. The conversational front door is real, but what sits behind it still rewards someone who understands the plumbing.
To be fair, it will help you with the plumbing too. When I hit the Slack credentials, I just asked, and it walked me through OAuth2 versus a bot access token and which one each Slack node needs.
This is a preview, so I expect that bar to keep dropping. For now, it lowers the effort, not the expertise.
Non-deterministic processes, and where a human belongs
Everyone is talking about non-determinism right now, and with it the shift from predefined processes towards goal-centric, dynamic flows, where an agent is handed an objective and left to find its own way there. There is real value in that. But the further the shift goes, the sharper the questions get, and nowhere more than in a regulated process. Who owns the decision being made? And if the goal is the same for every applicant but the journey to it is not, will people see that as fair and appropriate?
Set aside for a moment that applicants in the EU are covered by GDPR. Its Article 22 restricts decisions made solely by automated processing where they significantly affect someone, and where such decisions are allowed at all, it demands safeguards, including a right to human intervention. The UK has just rewritten its own version: the Data (Use and Access) Act 2025 replaces Article 22 with Articles 22A to 22D, which permit more automated decision-making but keep those safeguards. Even without the regulation, there is a simpler test.
Picture yourself as the head of admissions. A mother is in front of you, in tears, asking why her child was declined. In the same breath she tells you her child's best friend, same school, same classes, lower grades, got in, and her own child, after twelve years of hard work, did not. Now try telling her that the AI made the call, and that this is the fairest way to do it. Hard to justify, is it not? Someone has to be able to stand behind that decision, understand it and explain it to the person it lands on.
That is the balance. These tools are ready to take on far more than most people expect. Automate the gathering, the checking, the routing and the drudgery, and let a process run goal-first where the stakes are low. But keep a human accountable for the decisions that change a life.
Conclusion
I set out to see how far things had moved in a decade, so go back to the two pictures. The Level 3 overview and the more detailed models beneath it are still a perfectly valid way to capture a process. The running workflow at the top of this post is the simpler flow they inspired, live about two hours after I described it. What changed is not the analysis. It is that the analyst can now stress-test the design, build a better business case and ultimately make it run.
That is what the title is pointing at.
Rapid prototyping. A sentence becomes a running workflow in an afternoon.
Token costing. Every AI step reports what it spent, so the business case rests on real numbers rather than estimates.
A full-lifecycle tool. Design, build, run, observe and cost in one place, which is exactly what an Agentic Analyst needs.
None of it moves the line where a human has to sign. The rules still gate. A person still owns the decision. And someone still has to be able to explain the outcome to the mother standing in front of them. Get that balance right and the plain-language front door is not a shortcut around good analysis. It is what good analysis produces now.
A decade on, the map is the same and the job is not. From business analyst to Agentic Analyst, in the space of an afternoon. I will be using n8n again.
Terms
Plain-English definitions for the terms and tooling in this post, listed alphabetically.
Activity-based costing (ABC). A costing method that assigns the cost of resources, traditionally systems, people and materials, to the activities that consume them, then on to outputs such as a product, a service or a single process instance, using cost drivers. In agentic processes, token usage becomes one of those drivers.
Agentic Analyst (AA). My term for where the business analyst role is heading: the same analysis skill (outcome, boundaries, rules and exceptions), but the deliverable is a live, agentic workflow rather than a specification handed to someone else to build.
AI assistant (n8n). A preview feature in n8n that turns plain-language descriptions into workflow steps, generating and wiring nodes for you rather than requiring you to place each one by hand.
Data Table (n8n). n8n's built-in table storage for holding and tracking records inside a workflow, used here to keep applicant records as they move through the stages.
DeepSeek. A family of large language models, used here for the two AI steps that read and cross-check the transcript.
GDPR. The EU's General Data Protection Regulation. Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects, allows them only in limited cases such as contract necessity or explicit consent, and where they are allowed requires safeguards including the right to obtain human intervention. In the UK, the Data (Use and Access) Act 2025 replaced UK GDPR Article 22 with Articles 22A to 22D, which permit more automated decision-making while keeping those safeguards.
Level 3 process map (L3). One level in a process hierarchy: a model showing the sub-processes and phases within a business process. Typically one of a full suite of models a process architect produces and hands to a delivery team.
n8n. A workflow-automation platform for connecting apps, data and logic into pipelines. Workflows are built from nodes, with a visual editor and a large library of integrations.
Node. A single step in an n8n workflow: a trigger, an action, a branch, or a call to an app, model or piece of logic.
Token. The unit of text a language model reads and generates. Model usage is metered and priced per token, so token counts are the running cost of an AI step.
References
External sources referenced in this post.
Regulation
- EU GDPR (Regulation 2016/679), including Article 22 on automated individual decision-making. link
- UK Data (Use and Access) Act 2025: factsheet on the changes to UK GDPR, including the replacement of Article 22 with Articles 22A to 22D. link
Tooling
Let's talk
If you are experimenting with AI-assisted workflow builders or designing human-plus-AI processes, drop me a message. I am keen to compare notes on where these tools help and where they still need a human.