What this covers
- The expensive part of proposal work is finding and assembling existing material, not deciding what to offer.
- Client requirements are buried in email threads and attachments, and extracting them is a mechanical step.
- What is offered and at what price stays entirely with your team, and a deployment should say so plainly.
- Confidentiality is a design constraint here more than in any other sector, which shapes where the agent runs.
A professional services firm sells the time of people who are expensive. Which makes it worth asking, honestly, what those people spend their time on between the work that is actually billed.
The answer, in most firms, is documents. Assembling proposals from previous proposals. Rebuilding a methodology section that exists in four earlier versions. Extracting what a client actually asked for from a thread with six replies and three attachments. Producing the same project documentation for the fifth client this quarter.
The proposal, broken into its parts
| Part | Where it comes from | Who should do it |
|---|---|---|
| What the client asked for | An email thread, a brief, a tender document | Extraction: mechanical |
| Our understanding of the problem | The consultant's reading of it | The consultant |
| Approach and methodology | Previous proposals, adapted | Assembly, then the consultant's edit |
| Team and credentials | The firm's own records | Assembly |
| Relevant experience | Previous engagements, filtered for relevance | Assembly, then selection |
| Scope, price and terms | A commercial decision | The partner, always |
Three of those six rows are assembly. They are also, in most firms, the rows that consume the most elapsed time, because the material is scattered across a document store, previous proposals and individual people's memories of which engagement was similar.
The consultant should be editing a draft that already has the client's requirements extracted and the relevant precedents gathered.
Requirement extraction, which is genuinely tedious
Client requirements rarely arrive as a list. They arrive as a first email, a follow-up that adds two constraints, an attachment with a scope of work, a call summary, and a later message narrowing the timeline. Reconstructing the actual ask from all of that is a careful reading exercise that takes an hour and produces nothing billable.
An agent reads the whole thread, including the attachments, and produces the structured version: what is being asked for, the constraints, the dates, what was added or changed later, and what was asked but never answered. The last of those is frequently the most useful output, because the unanswered question is the one that causes a scoping problem later.
The line that does not move
It is worth being blunt here, because the sector is understandably wary. An agent does not decide what your firm offers, what it costs, or what you are willing to commit to. Those are the judgments clients are paying for, and automating them would be selling something other than professional services.
What it does is arrive at the point of judgment with everything prepared: the requirements extracted, the precedents gathered, the credentials assembled and the standard sections drafted from your own approved material. The partner edits and decides. Where the agent stops covers how that line is set explicitly rather than assumed.
The back office behind the billable work
Proposals get the attention, but the steadier drain is the operational administration that surrounds the delivery.
- Routine client requests: status, documents, previous deliverables, invoice queries.
- Document requests that involve finding something somebody produced eighteen months ago.
- Supplier and subcontractor invoices, matched against engagements and approved.
- Purchasing services and materials for a project, including the chasing.
None of these are intellectually demanding and all of them currently interrupt people who were doing something else. Customer operations automation and invoice processing cover those two patterns in general form.
Confidentiality as a design constraint
This sector has a constraint the others have in weaker form: client documents are frequently covered by confidentiality undertakings that restrict where they may be processed and who may see them.
That has a concrete implication for deployment. The agent runs inside your own infrastructure and works directly in your systems, so client documents are not copied into a shared service to be processed. Where model inference runs, and the data terms that apply to it, are agreed before deployment and named explicitly rather than implied. In a sector where you may have to answer that question in writing to a client, that distinction is not a technicality.
Security sets out the deployment boundary, and AI agents for B2B services covers the workflows.