For a long time, when I thought about automation, I thought in terms of tasks. A repetitive click. A form someone had to fill out every day. A message that followed a predictable structure. A piece of information that had to be copied from one system into another. These were obvious candidates because they were easy to see and easy to describe. Someone would point at a step and say, “Can we automate this?” and, most of the time, the answer was yes.
But after working across both engineering and operations at Gradly, I started noticing that the task itself was rarely the thing consuming most of the time.
The real work was everything around it.
A support person might receive a customer request, figure out what the customer is actually asking, check their plan, look up account details, read previous conversations, verify something in another system, decide what rule applies, draft a response, escalate the case if something looks unusual, and then remember to follow up later. Writing the response might only take a few minutes. Automating the response saves those few minutes. The rest of the job is still there.
Once I started looking at workflows this way, the unit of automation changed for me. Instead of asking what task I could remove, I started asking what responsibility the system could own.
That distinction sounds small, but it changed how I build things.
The task is usually not the job
One of the clearest examples was the AI insurance concierge we built at Gradly.
It would be easy to describe it as a system that writes customer support replies. Technically, that is one of the things it does. But “generate a reply” was never the interesting problem.
A useful support reply depends on a surprising amount of context. The system may need to understand which university a student belongs to, which plan they are enrolled in, what that plan covers, what has already been discussed with them, whether a particular exception applies, what information exists in our CRM, whether the request should be escalated, and sometimes what another internal system says about their account.
If all I automated was the final writing step, I would still need a person to gather all of that context manually before asking the model to produce an answer. The reply might be generated faster, but the support workflow would barely change.
So the system became broader than that. It brings together plan knowledge, customer context, conversation history, internal information, and operational rules before drafting a response for human review. The model is only one part of the system. The real automation is the chain of work that normally happens before someone can confidently hit Send.
That was when I started thinking less about automating the task of “writing a reply” and more about automating a meaningful part of the support role.
The same pattern showed up in claims.
Automating claims adjudication sounds simple if you reduce it to individual actions. Read a bill. Extract some fields. Check eligibility. Trigger a payment. Each of those can be treated as its own automation project.
But that is not how the work actually happens.
A claim has to be understood. The person reviewing it needs to know what the expense is, whether the member was eligible, whether the supporting information is sufficient, whether the claim falls under the plan rules, whether something looks inconsistent, whether the case can proceed automatically, and what should happen next. Once a decision is made, the financial side still has to move through the correct process.
The interesting opportunity only appeared when we stopped looking at those as disconnected steps.
A system could ingest the supporting documents, interpret the claim, pull the relevant account and policy information, run deterministic checks, surface ambiguity where it exists, make straightforward decisions where the rules are clear, and then continue into the payment workflow. A human does not need to supervise every transition. They need to become involved when the system reaches a decision boundary where judgment or missing information actually matters.
That is a very different architecture from adding automation to individual clicks.
It is also a very different product.
VisaFile made this even more obvious to me.
On paper, filling a DS-160 looks like a form-filling problem. If I had framed it that way, the project would have been about taking user input and mapping it into fields on a government website. Useful, maybe, but not especially interesting.
The real job is much bigger than filling fields.
Someone has to collect the right information from the applicant, make sure required details are present, translate that information into the structure expected by the DS-160, move through a long multi-step application, preserve state when the website behaves unpredictably, handle validation errors, pause when a CAPTCHA or security check requires a person, recover when something fails, and eventually produce the confirmation the applicant actually needs.
That is the workflow I tried to automate with VisaFile.
The user goes through a guided intake instead of dealing directly with the full complexity of the government form. Behind that, a worker takes the collected information and progresses through the DS-160 flow. It keeps persistent state, reports progress back to the product, pauses for things that should not be automated, such as CAPTCHA or a correction that needs the applicant, and can continue once that human input is provided.
The goal was never “autofill a visa form.”
The goal was to own as much of the visa application preparation workflow as the system reasonably could, while being explicit about the points where it should stop.
That distinction matters because the hard parts were not the text fields. They were state, recovery, validation, external website behavior, security checks, and deciding where human intervention belonged. Automating one field would have saved seconds. Automating the responsibility around the form could save someone from navigating most of the process themselves.
VisaFile also reinforced something I had already started seeing in the Gradly systems: good automation is not necessarily the one with the least human involvement. It is the one where human involvement happens at the right places.
A person should not need to supervise every click. But if the system encounters a CAPTCHA, an ambiguous answer, or something that could materially change an application, stopping and asking for help is the correct behavior.
The automation is better because it knows its boundary.
Role-level automation changes the process
I have come to think that task automation often optimizes the process you already have. Role-level automation forces you to question whether the process should exist in the same form at all.
If someone spends five minutes copying data between two systems, it is natural to automate the copy. But maybe the more important question is why the systems are separate in the first place. Maybe the person copying the data is also validating it, making a decision, notifying someone else, and then updating a tracker. You can save five minutes by automating the copy and still leave twenty minutes of coordination untouched.
This happens constantly.
A workflow becomes slightly faster at one step, but the handoffs remain. People still move between tools. Context still has to be reconstructed. Someone still has to remember what happens next. A faster task can even create more work downstream if it causes information to move before another part of the process is ready for it.
The biggest gains I have seen usually come from removing those boundaries rather than making individual actions faster.
That also changed the questions I ask when I spend time with an operational workflow.
I care less about which click is repetitive. I want to know what the person is ultimately responsible for producing. I want to understand what information they gather before making a decision, which parts of that decision are deterministic, which parts actually require judgment, what the common exceptions are, and what happens immediately before and after the task everyone thinks they want automated.
Sometimes the best way to answer those questions is not to start building anything.
It is to watch someone work.
When you shadow a workflow for a few days, you start seeing things that never appear in the written process. Someone checks Slack before replying because they know a particular partner tends to send updates there first. Someone opens a previous ticket because the internal documentation is slightly out of date. Someone knows that a certain category of case almost always needs escalation, even though the official workflow says otherwise.
Those behaviors are often the real process.
If you automate only what is easiest to see, you automate the interface around the work and miss the work itself.
This is also where exceptions become useful. Exceptions show you where the limits of the system actually are.
If ninety percent of cases follow a clear path and ten percent need judgment, designing the whole workflow around the ten percent is usually a mistake. The system can own the normal path and stop when something unusual happens. The human can then spend their time on the cases that genuinely benefit from interpretation, negotiation, empathy, or domain expertise.
A good automated system should know when to stop.
That sounds obvious, but a lot of AI systems are designed as if success means allowing the model to keep making decisions indefinitely. In practice, I would rather have a system that confidently handles the normal path and produces a very clear “I need help here” state than one that tries to reason through every edge case.
Human review works better at meaningful decision boundaries than after every individual step.
Automating a role is not automating a person
There is an important distinction here that I did not appreciate at first.
When I say I think about automating roles, I do not mean automating entire people.
A role is a collection of responsibilities. Some of them are repetitive. Some are deterministic. Some involve gathering information. Some involve coordination. Some involve judgment, relationships, negotiation, creativity, or dealing with genuinely novel situations.
Those should not be treated as the same kind of work.
The useful question is whether there is a coherent chunk of responsibility that a system can own from beginning to end.
In support, that might be handling common policy questions where the relevant information is available and the rules are known. In claims, it might be processing straightforward cases that satisfy all of the required checks. In operations, it might be coordinating a workflow that currently requires someone to move information across four different tools. In something like VisaFile, it might be owning the normal application-preparation path while stopping when the process reaches a point that genuinely requires the applicant.
The remaining human work does not disappear. It changes shape.
Instead of spending time assembling context, copying information, and making the same low-risk decision repeatedly, the person can focus on exceptions, judgment, customer relationships, and cases where the answer cannot be derived cleanly from the available information.
That is a more precise way to think about automation than saying AI will replace a job.
Most jobs are not one thing. They are bundles of very different kinds of work.
Software is better at some parts than others.
AI is only part of the system
Another thing I learned quickly is that role-level automation usually needs much more than AI.
The model may be the most visible part because it handles language, ambiguity, classification, or synthesis. But the surrounding system is usually doing just as much work.
You need APIs to retrieve information. You need deterministic business rules for things that should not depend on model interpretation. You need data pipelines so the system has current information. You need notifications when something requires attention. You need approval steps when a decision should remain human. You need integrations with the tools where the actual work happens. You need logs so you can understand why the system behaved the way it did.
Sometimes you need a model to interpret a document, but you definitely do not need a model to decide whether a payment amount exceeds a configured threshold.
Sometimes you need a model to understand what a customer is asking, but you probably want deterministic software to retrieve their enrollment status.
Sometimes you need a model to draft a response, but the rule determining whether the response requires approval may be completely explicit.
And sometimes, as with VisaFile, the core automation barely needs AI at all. The hard part is orchestrating a reliable process across a brittle external system, maintaining state, handling failures, and knowing exactly when the system should hand control back to a person.
The most reliable systems I have built combine these approaches.
AI handles the parts of the workflow where the input is messy or the meaning needs to be inferred. Traditional software handles the parts where the answer should be predictable.
Trying to make the model do everything usually makes the system harder to trust.
The goal is not to build the most autonomous-looking system. The goal is to build one that can reliably own a useful piece of work.
That has become the way I think about automation now.
When I see repetitive work, I try not to immediately ask which task I can automate. I try to understand the responsibility around the task first.
What is the person actually trying to accomplish? What information do they collect before they can do it? What decisions do they make along the way? Which of those decisions have clear rules? Which ones depend on judgment? What happens after the decision? Where do cases leave the normal path? Where would a human genuinely add something the system cannot?
Once you look at work that way, the individual task starts to feel less important.
It is often just an implementation detail of a larger responsibility.
And that responsibility is usually where the real automation opportunity is.
So when I look at repetitive work now, I try not to ask which task I can automate.
I ask what responsibility the system could reasonably own from beginning to end.
Thanks for reading.
More about Animesh