Quick summary: An agentic workflow is a process where an AI agent does the routine steps and hands the rest to a person, within rules your firm has written down. In a consulting firm, the best place to start is timesheet approvals and turning an SOW into a project plan, because both happen all the time and are easy to describe as rules. Naming people on projects and talking to clients should stay with people, although AI can make suggestions. Most of the work is in writing down how your firm handles its processes and handovers, and then letting the agents follow that.
Most consulting firms I talk to have their processes written down somewhere. At one small development agency, everything from a new sale to project start lives in Confluence. It works for the operations lead because he wrote it, but the others follow it only occasionally, and if he left, the know-how would mostly leave with him.
A nearshore software company keeps its procedures in Notion and already runs agents on top of them. One builds the monthly invoices, and another checks that timesheets are in and roughly match the plan. A person still clicks send on the invoice email, though, because a wrong invoice can cost you the client relationship.
That's roughly where most firms are right now. The processes exist and a few simple pieces already run on their own, but most of it still depends on someone remembering to do it.
I'm the founder of Operating, a PSA platform for consulting firms, and we're building this kind of layer on top of our platform, so my opinion will inevitably be biased. Most of what follows comes from calls with operations people at consulting firms over the past year.
What is an agentic workflow?
An agentic workflow is a process where an AI agent does the steps a person used to do. It reads the data, makes the routine decisions within the rules your firm has set and passes the rest to a person. In a consulting firm that could be turning a signed SOW into a project plan, or approving a timesheet that matches the plan. A notification telling someone to go and do the work doesn't count, since a person still does the work.
Anthropic makes a useful distinction in its guide to building effective agents. In a workflow the steps are set in advance, while an agent decides its own steps as it goes. Most of what happens in a consulting firm's operations is the first kind. The steps are known, and the agent does the work inside them.
Agentic workflows start with a written process
Most of the talk about agentic workflows is about the agents, like which ones to build and what each one does. In my opinion that's the wrong level to think at. What an operations lead actually wants is the hours approved and the invoices out on time, and whether an agent or a person does it comes second.
Building a couple of agents is a fine first step, and most firms will start there. The trouble starts when building agents becomes the goal. You end up with a bunch of small bots, each with its own instructions, and someone has to remember how they fit together. It's a bit like saying you're there to build workflows. You aren't. You're there to get something done, and the workflow is just how you get there.
With AI you can skip that layer. You describe your process in plain language: what happens when a deal is signed, who approves the hours, what counts as a change request and where the limits are. The system then works out which agent does what. When the process changes, you edit the description and the agents follow it, instead of someone rewriting five separate bots. That's also the idea behind the Operating Method, a written-down set of processes a firm can adopt, adjust and have agents run.
We discussed this internally, and our CTO, who has a military leadership background, compared it to giving orders. You write explicit instructions with clear limits, and the difference to managing people is that you don't have to think about anyone's feelings.
The processes and handovers in a consulting firm
A consulting firm is basically a chain of handovers, where one step produces something the next step needs.
- A deal reaches the proposal stage in the CRM, and the seller turns the discovery call notes into a scope.
- The seller, often together with a resource manager, puts the roles on a plan before anyone has a name. The estimate and the price come from that plan.
- The scope and the price become a statement of work with terms, which gets negotiated and signed.
- Once it's signed, the staffing manager puts names on the roles and sorts out conflicts with other projects.
- The project owner sets up the budget and invoicing schedule, watches burn against the plan and writes a change request when the client asks for more.
- Everyone logs their hours, and someone, usually the project owner, approves them.
- Finance turns approved hours and finished milestones into invoices, checks them and sends them.
- Finance closes the month, which means recognizing revenue and sending hours to payroll.
Around that chain sit the things that keep the firm itself running. Leadership sets the budget and targets for the year and replans when the numbers move. Someone, usually the COO or the head of delivery, looks across all the projects every week or month and decides where to step in. And when the pipeline shows more work than people, someone has to decide whether to hire, and then actually hire. None of this belongs to a single project, but it runs on the same data and feeds the chain, with targets going to sales and hiring plans going to staffing.
Most of the pain is in the handovers. Someone, usually the sales person, has created a pricing estimate, and it's in a spreadsheet. That's typed into the PSA or resourcing tool by hand. When a deal moves to closed won, it doesn't necessarily mean that the case is ready to be staffed. The SOW has all the details for a change request, but people don't check for that, and they tend to go rogue instead. This causes inconsistent ways of handling budget changes, for example, which then, again, hurts your bottom line.
The contracting step is the one most process maps leave out, and a lot of the later trouble starts there. Billing milestones, rate caps, what counts as a change and whether the client approves hours are all decided in the SOW. If those terms never make it into the project, everyone after that works from memory, and that's usually where unbilled work and surprise write-offs come from.
Triggers and cadences: what starts a process
A process starts in one of two ways. Either something changes in the data and triggers it, or it runs on a cadence because it's simply time to do it.
The chain above is trigger-based. A deal reaching a certain stage in the CRM starts it, and resourcing, pricing and the SOW follow from there. Triggers can come from anywhere in the data, though. When utilization in a team drops below the level you've set, the agent can start a bench check and list who's coming free and which deals in the pipeline could use them. When planned and actual hours drift apart, it can dig into where people are losing time, so the project owner hears about it while there's still budget left to fix it.
The rest runs on a rhythm, and most firms already have these meetings and checks. They're just prepared by hand, usually by the one ops person who knows where everything is. Every week there's the staffing meeting, and the agent can have the open roles and the people rolling off ready before anyone walks in. A weekly data check can catch projects with missing metadata and timesheets that weren't submitted, which otherwise turn up at month-end when finance is trying to invoice. Once a month the agent can put the sales pipeline and the hiring pipeline side by side for review. Every quarter it prepares the budget for the next one, and once a year the annual budget.
In both cases the agent does the legwork and has the material ready, and people make the decisions.
Three kinds of work in an agentic workflow
Once the processes are written down, every step gets a default.
Some steps the agent simply does, and nobody looks unless something breaks. Prefilling timesheets from allocations and calendars, drafting invoices from approved hours, setting up a project from a signed SOW and releasing tentative bookings when a deal is lost all fit here.
Some steps the agent does inside limits you set. These are often called "guardrails" in an agentic context. An agent approves timesheets that match the plan within a certain deviation and change requests below a certain size, and once you trust the drafts, it sends the invoices too. Anything outside the limits goes to a person, with the reason attached so they don't have to dig for it.
The rest stays with a person, like deciding who works on what or handling the client when things go sideways.
These defaults are a starting point. A firm sets them once and then adjusts them per client and per project. Invoices to a retainer client you've billed for six years can go out without anyone looking, while a new client in a tricky first quarter can have every invoice checked. A fixed-price project with a thin margin can send every timesheet deviation to the project owner, while internal projects approve themselves.
The defaults should also get better with data. If an approver accepts almost every timesheet the rule flags for one client, the limit for that client is too tight and it's just creating busywork. If projects that get staffed in the last week before kickoff keep running over budget, the staffing deadline should move earlier. The data for this is already in the system, so the rules can improve every month instead of going stale like those Confluence pages.
Invoices are a good example of limits that change over time. For the first couple of months, a person checks every one. Then a small share goes out unchecked and gets spot-checked afterwards, and that share grows as the drafts keep being right. It's the same as with a new hire, you check less once you trust the work.
Below is the starting point we'd suggest. Every firm will move some of these around, and they should.
What to automate first in a consulting firm
Start with timesheet approvals and SOW to plan. Both are easy, and that's exactly why they should go first.
Most approvers already rubber-stamp timesheets. They open the week's entries, usually on a Friday afternoon, and approve the ones that match the plan one by one. A rule can do that. Approve automatically when the hours are close to the allocation and every entry has a note, and flag anything odd, such as weekend hours on a project that never has any or a sudden jump in non-billable time. The approver then only looks at the flagged ones, with the reason they were flagged. I'd set the rule at company level, so one relaxed manager can't approve everything that comes in and leave finance to find the problems at month-end.
SOW to plan is easy because the information already exists in writing. Today someone reads the SOW and types it into another system. One operations lead I talked to went from SOW to a staffed project plan in about 15 minutes, when it used to take him an hour or two, mostly spent jumping between different tools to find out who's free.
The agent can also start earlier, from the discovery call notes. It places the roles on a plan based on similar projects the firm has done before, and prices the work from that plan. Then it writes the whole SOW, which the firm can try out with the client. Where the notes don't say, it asks the seller a couple of questions. The roles stay without names until the work is signed, and picking the actual people is a different job, which I'll come back to below.
You can try both of these today on any platform that has an MCP server. Write the rule down in plain language and run it as an automation in Claude Cowork or Codex, connected to your systems through their MCP servers. Both can run automations on a schedule, which covers the cadence-based work above. Some of our customers already turn SOWs into project plans this way with our MCP server.
After those two come invoice drafts from approved hours and milestones, change requests when a client asks for more than the SOW covers, weekly health checks for project owners and the month-end close. All of them depend on the hours and the plan being right, which is the other reason to start with timesheets and the SOW.
What stays human
Naming the people stays with people. Placing roles on a plan is easy for an agent, but once the work is signed and the roles need names, the agent should only rank candidates and explain why: skills, availability, who's coming off which project, who has been on the bench too long. Who works with which client is one of the biggest decisions a consulting firm makes, and most of what goes into it isn't in any system, like who wants to grow into what or who didn't get along with the client's CTO last year. The person running operations at that nearshore firm said the same thing. For them the client relationships are the thing most worth protecting, because good work with a client is what leads to the next project. I agree with him.
The client conversation stays human too. The agent can draft the change request with the hours and the effect on the plan, but the project manager decides how and when to bring it up with the client.
He also pointed out something that's easy to miss, which is that automation lowers oversight. If an agent checks that someone logged 40 hours, you know 40 hours were logged. You don't know if they were useful hours or "Monday 8, Tuesday 8, Wednesday 8" typed in on Friday afternoon. A manager reading timesheets would notice, but a rule that only checks totals won't, and that's how a client ends up asking what they actually paid for.
According to him, the hardest part of automating his firm was the rules people follow without ever saying them out loud. Write those down too. If notes on time entries matter to you, put it in the rule. If one client always wants more than they budgeted for, put that in as well.
And get the data right before you automate on top of it. An agent approving timesheets against a plan nobody has updated will approve the wrong things, and it will do it faster than a person would.
In the firms I've seen get furthest with this, someone had sat down and written up their processes, including the parts everyone thought were obvious. After that, the agents were the easy part. Which is a slightly awkward thing for a software founder to admit.
FAQ
What is an agentic workflow in a consulting firm?
It's a process where an AI agent does the routine steps a person used to do, like approving timesheets that match the plan or turning a signed SOW into a project plan. Anything outside the rules your firm has set goes to a person.
What should a consulting firm automate first?
Timesheet approvals and SOW to plan. Both happen constantly and are easy to write down as rules. Everything later in the chain, from invoicing to the month-end close, also depends on the hours and the plan being right.
What shouldn't be automated?
Naming people on projects and the client conversation. An agent can rank candidates and draft the change request, but the decisions depend on things that aren't in any system.
Do you need special software to build agentic workflows?
No. Any platform with an MCP server can be connected to tools like Claude Cowork or Codex, where you can run your rules as scheduled automations. What you do need is your processes written down in plain language.
