Agentic Re-Staffing on Scope Change

Re-staffing should start only after a commercially binding change exists. A Slack thread, a verbal "we should add this," or a detector flag is not enough. Those signals help the engagement lead. They are not permission to pull people off other clients.

The expensive part of a scope change is not noticing it. It is the cascade: you add a workstream, you need a skill the current team does not have, you pull someone from another live engagement, and that engagement now has a hole. Do that on a rumor and you spend political capital you cannot get back.

Treat the scope creep detector as an upstream warning, not as a trigger. It tells you requests are accumulating outside the SOW. Until the work is priced, signed, and recorded as an approved change order or executed amendment in the PSA, the roster does not move.

Wire detection to the system of record, not to chat:

• Listen for change-order or amendment status in Kantata, Planview, Forecast.app, Mosaic, or the PSA you already run.
• Require a signed-or-equivalent state. Draft, in review, and "client said yes on the call" are not events.
• Pull the delta the commercial team already entered: added deliverables, role types, hours, dates, and location or clearance notes.
• If the change order is cancelled or reversed, drop any open staffing proposal based on it.

The output of this step is a structured event: engagement ID, before/after scope, commercial effective date, and the roles the CR actually funded. Without that, the optimizer is guessing.

Once the event is real, re-optimize staffing across the portfolio and return a proposed swap list. Every line is a recommendation for a staffing lead and the affected engagement managers. The agent does not edit the live roster, does not place calendar holds, and does not email the people it wants to move.

PSA and resource tools in this class already store assignments and, often, the change-order object. Read bookings and availability from them. Do not grant the agent write access to assignments. After humans approve a line, a person applies it in the tool the firm already uses to staff work.

A proposal line that a PMO can actually review includes:

• Who leaves which role, who is proposed in, and on which dates.
• The signed delta that created the gap, so the ask traces to the CR rather than to a stale skill tag.
• Fit evidence from the skills-to-project matching engine, shown separately from availability.
• Knock-on load from the utilization and bench risk predictor: whether the donor engagement goes short, and whether the move only relocates the crunch.
• A stability note: how many live clients the person currently faces, and whether they were moved recently.

If no candidate clears hard constraints, return no viable swap. That is a complete answer. It tells the partner to hire, subcontract, or take the date slip back to the client. Filling the slot with a weak match converts a commercial win into a delivery problem.

Take a four-person ERP implementation in week ten of a fixed go-live. The client signs a change order that adds a historical data-migration workstream and a funded migration-lead role, without moving the date. The PSA marks the CR approved. That status change is the trigger.

The agent should not propose replacing the engagement partner because a cost function prefers a cheaper mix. The partner is why the client staffed you. The gap is a migration lead who can work the window, has done this class of cutover, and can be on-site if the CR requires it.

A reviewable proposal might read: bring in a manager who is finishing a close-out on another account, backfill that manager's remaining wrap-up from the bench, and leave the current partner and day-to-day manager in place. The staffing lead then talks to both engagement managers. If the donor side is still in a client-visible cutover, the line is rejected. Nothing in the live roster changes until those conversations happen.

The example is a pattern, not a measured result. Preserve relationship roles. Move the scarce skill. Make the knock-on visible. Stop if the donor engagement cannot absorb it.

The fastest way to lose the room is a proposed swap of a client-facing partner or named engagement lead. Encode anyone named on the SOW, and anyone the client greets by name, as immovable by default. A partner can unlock that person. The model cannot.

The next failure is eligibility. Skills vectors do not know about competitor conflicts, visa limits, travel-week caps, or security clearance. If those fields are blank in the PSA, treat the person as ineligible for any move that would require them. Missing data is not "no constraint."

Encode at least these before you run the optimizer:

• Named and relationship roles. Partner, engagement manager, and client-facing leads stay put unless the originating partner unlocks them.
• Clearance and citizenship. Spare hours do not put someone on a cleared program.
• Visa and location. A consultant who cannot work in the client's country is not available for that CR.
• Conflicts. Do not place someone who just advised the client's competitor onto the new workstream.
• Recent moves and recovery. Low utilization after a brutal go-live is not spare capacity.
• Interest. Use the consultant preference and interest matcher so you stop recycling people into work they have asked to leave.

Fail closed when a constraint field is empty. The staffing lead can override in writing. The agent should not fill the gap with optimism.

The swap list is a ticket queue, not an accept-all control. Different lines need different humans:

• Named lead or partner on either engagement: both partners. Staffing cannot approve this alone.
• Scarce specialist who is currently client-facing: both engagement managers, then staffing.
• Bench into a new role with no backfill: staffing lead can approve, and the receiving manager is informed.
• Any exception on visa, clearance, or conflict: commercial or risk. Not the model, and not a staffing dashboard acting alone.

Run the first period in advisory mode. Compare proposals with what resourcing actually did. Capture rejection reasons: relationship, eligibility, timing, or hours on the CR that do not match delivery history. Those rejections show when the model is optimizing the wrong thing.

Do not improve the system by letting it execute the lines that would have been rejected. When a line is approved, a human keys it into the PSA. The agent may attach the ticket ID for audit. It still should not hold write credentials to the assignment table.

Check the funded hours against effort estimation from historical actuals. If the CR adds a role at hours the firm's history says are too light for that work, flag the hours conflict instead of staffing someone into a plan that will slip. That is a commercial conversation, not a roster conversation.

This use case is high effort because the hard parts are operational. You need change-order states people trust, eligibility fields that get maintained, and an approval path partners will actually use on a Thursday afternoon.

Keep these off the agent even after advisory mode:

• Writing assignments, holds, or staffing messages without a human applying the change.
• Default-moving anyone named on the SOW, or anyone the client treats as the face of the firm.
• Treating chat, meeting notes, or unsigned CRs as staffing events.
• Hiding knock-on effects so a swap looks local when it is not.
• Scoring a person available when conflict, visa, clearance, or location is missing.

If those refusals feel like they remove the point of an agent, the point was the wrong one. The speed worth buying is the time from a signed change order to a reviewed swap list in front of the right approvers, not the time to a silent edit of the live roster.