Blog article
What to Do When an AI Builder Hire Is Not Working Out
A practical postmortem guide for employers when an AI Builder's first 90 days are not meeting expectations, covering role promises, workflow choice, business ownership, permissions, technical support, candidate fit, recovery plans, and exit decisions.
AIBuilderTalent Editorial
Editorial Team
Practical notes on AI Builder hiring, role design, and profile quality.
Weak progress does not always mean the wrong hire
When an AI Builder's first 90 days are not going well, the employer may quickly conclude that the person is not senior enough, not proactive enough, not technical enough, or not business-oriented enough. Sometimes that conclusion is correct. But without a postmortem, it is easy to blame the hire for problems created by the role, the workflow, or the company.
AI Builder performance depends heavily on the operating conditions around the role. The person needs a real workflow, a business owner, users, usable data or documents, permission boundaries, technical support, and evidence-based success criteria. If those conditions are missing, the first 90 days may be measuring organizational readiness more than individual capability.
The point of a postmortem is not to excuse weak performance. It is to separate candidate fit from role design. Is the person failing to do the work, or was the work never made executable? The answer determines whether you should provide support, change the first workflow, narrow the role, run a short recovery plan, or end the relationship.
If the review ends with only "they are not working out," the company has not learned enough.
Reconstruct the original agreement
Start by writing down what the role was supposed to be when the offer was made or when the person started.
Use a simple record:
Original first workflow:
Business owner:
Initial users:
Available data, documents, and systems:
Risk boundaries:
Technical support:
30/60/90-day evidence:
What the AI Builder was expected to own independently:
What the company promised to provide:
If these items were never defined, that is part of the postmortem. Do not evaluate the person against standards that only became clear after they joined.
For example, if the offer described a workflow-focused role with engineering support, but the first project became independent production ownership across authentication, logging, deployment, monitoring, and CRM integration, the role changed. That may still be a valid business need, but it is not the same job.
The opposite can also happen. If the first 30 days clearly required a workflow map, first-release scope, test examples, and risk boundary, but the AI Builder stayed in generic tool research, that is stronger evidence of performance or fit risk.
Before judging progress, make sure the standard is real.
Separate symptoms from causes
Managers usually see symptoms first. There may be several demos but no real users. The first workflow may still be too broad. Business teams may say the tool is interesting without adopting it. The project may be blocked by data, permissions, or system access, while engineering warns that the current approach cannot be productionized. Leadership may see activity without business evidence. The AI Builder may keep waiting for clearer instructions before moving.
These symptoms matter, but none of them is a complete cause.
"No real users" might mean the AI Builder avoided user discovery. It might also mean the business owner never assigned pilot users. "Blocked by permissions" might mean the AI Builder failed to identify risk early. It might also mean the company has no approval path. "Only demos" might mean the hire is prototype-oriented. It might also mean leadership kept asking for new ideas instead of one workflow.
Before reaching a conclusion, slow the review down. Ask when the symptom first appeared, what the AI Builder actually did, what support the company promised, and which precondition did not exist. Then make the harder call: if that missing condition were fixed, would the outcome likely change, or would the same capability gap still remain?
This keeps the postmortem evidence-based. It also prevents the company from repeating the same failure with the next hire.
Diagnosis 1: the first workflow was wrong
Many weak starts happen because the first workflow was poorly chosen.
The warning signs are usually practical, not abstract. The workflow may be too low-frequency to create usage, or the source material may be too outdated and conflicting to support trusted output. The error cost may be too high for a first project. The work may cross support, legal, sales, and operations without a clear decision owner. Sometimes the project quietly requires deep production integration, but engineering support was never allocated. In weaker cases, the business problem is vague and the workflow exists mainly because someone said "AI should help here."
The signal is often visible. The AI Builder may have named the risks correctly, but the project still cannot reach a real pilot. They may have pointed out that legal review is needed, customer data cannot go into an unapproved tool, CRM access is blocked, or the workflow should remain internal first. If the company keeps asking them to "just build something," the issue may be workflow choice.
The fix is not automatically to replace the person. It may be to narrow the workflow.
Change "customer-facing automated replies" to "internal response drafts for support agents." Change "company-wide knowledge assistant" to "contract process questions for the sales team." Change "automatic approval" to "pre-check for missing approval materials."
Evaluate the hire inside a workflow that can actually be tested.
Diagnosis 2: the business owner never showed up
An AI Builder cannot permanently substitute for business ownership. Without a business owner, projects often stall in a vague state: everyone is interested, but no one decides the scope.
Business-owner absence has a recognizable shape. The AI Builder can get casual interest but not time with the accountable leader. Users are willing to chat, but no one defines acceptance criteria. Every team suggests ideas, but no one chooses the first release. Risk boundaries are discussed in meetings and then left without an approver. The project changes direction each week because the loudest executive interest becomes the new priority.
Do not automatically read this as lack of initiative. A strong AI Builder should push, document, propose options, and escalate blockers. But they cannot create organizational priority alone.
Ask the business owner three direct questions:
Is this workflow still important?
Will you participate weekly in scope and review decisions?
Which decisions belong to you, and which decisions belong to the AI Builder?
If no one can answer, either name a real owner or change the goal. The first 30 days may need to become use-case selection instead of delivery. That is a different role shape and should be evaluated differently.
If a strong business owner exists and the AI Builder still avoids users, does not turn feedback into decisions, or waits passively for tasks, then the concern is more likely candidate fit.
Diagnosis 3: data, permissions, or technical support did not exist
AI Builder projects often fail on inputs and access before they fail on models.
Classify the blockers:
Data and document issues: outdated sources, conflicting policies, missing ownership.
Permission issues: accounts not granted, approval owner unclear, sensitive data restricted.
System issues: unavailable APIs, unstable fields, no production environment access.
Security or compliance issues: privacy review, logging, approved tools, audit requirements.
Then examine the AI Builder's behavior.
Strong AI Builders usually make these constraints visible early. They create an input inventory, mark which sources are usable, restricted, outdated, or excluded, and propose a lower-risk internal version when full access is not available. They ask for the right owners instead of treating sensitive data as ordinary prompt material. They also separate prototype feasibility from production readiness, which keeps a promising demo from being mistaken for a deployable workflow.
Weak signals point in the other direction. The AI Builder discovers access problems late, stops moving when a preferred data source is unavailable, bypasses approval paths, or uses sensitive customer, employee, financial, legal, or health-related information in unapproved tools. Another common concern is vagueness: they cannot say what technical support they need, so every blocker becomes a general engineering problem.
If the company has no permission path, create one before blaming the hire. If the AI Builder lacks basic boundary judgment, more access will not fix the problem.
Diagnosis 4: the candidate is genuinely mismatched
The postmortem should also recognize real candidate-fit problems. Some signals are about the person, not the environment.
High-risk signals usually show up as repeated judgment problems. The AI Builder starts with tools before understanding the manual workflow, cannot narrow a broad request into a first release, or treats every failure as a prompt or model issue. They ignore human review in customer-facing or high-consequence workflows, show poor sensitivity around employee, customer, financial, legal, health, or security data, or cannot state what moved forward, what is blocked, and what evidence comes next. Blaming the company for every blocker without proposing a lower-risk path is also a serious concern, especially in a role that was hired to reduce ambiguity rather than wait for a complete task list.
These concerns are especially serious if the company provided a clear workflow, a business owner, user access, data access, risk boundaries, and technical support.
Use evidence, not personality labels. "Not proactive" is weak. "For two weeks, did not confirm scope with the business owner, did not submit a blocker list, and did not turn user feedback into categories or next actions" is stronger and fairer.
AI Builder roles can accommodate experience gaps. They cannot accommodate a persistent absence of workflow judgment, risk awareness, and delivery closure.
Read the 30, 60, and 90-day signals differently
Weak progress means different things at different stages.
By day 30, focus on workflow understanding and scope control. A candidate risk is visible if the AI Builder has researched tools but cannot name the users, inputs, outputs, failure cost, and first-release boundary. An employer risk is visible if the company still has no business owner, initial users, or usable inputs.
By day 60, focus on real usage. A candidate risk is visible if progress exists only in executive demos, or if user feedback exists but has not been categorized or prioritized. An employer risk is visible if users were never given time to test the workflow or system access has no approval path.
By day 90, focus on decision and ownership. A candidate risk is visible if the work is still in indefinite iteration with no expand, continue narrowly, stop, or pivot recommendation. An employer risk is visible if success criteria were never defined and the final review relies on subjective impressions.
The recovery action should match the stage. Day 30 may need role clarification and owner assignment. Day 60 may need real users and a feedback loop. Day 90 usually requires a clear decision: short recovery, role adjustment, or exit.
Run a two-week recovery plan, not vague observation
If the problem is still recoverable, do not say "let's watch for a few more weeks." Observation without a specific plan only extends ambiguity.
A useful recovery plan should define:
Core problem to fix:
Whether the first workflow changes:
Business owner and weekly review time:
Evidence the AI Builder must deliver:
Support the company must provide:
Risk boundaries that cannot be crossed:
Decision criteria at the end of two weeks:
Example:
Core problem: support assistant exists as a demo, but there is no real user evidence.
Workflow adjustment: internal response drafts only; no automatic customer replies.
Business owner: support lead reviews scope and feedback every Tuesday.
AI Builder evidence: five support agents try the workflow, 20 real questions are categorized, errors are grouped, and the next release priority is written.
Company support: provide anonymized ticket examples, help center access, and user time.
Risk boundary: refund, complaint, and contract questions require human approval.
Decision criteria: if there is still no real usage evidence after two weeks, pause the project and reassess role fit.
The plan should bind both sides. Asking the AI Builder to "be more proactive" while withholding users, inputs, and decision owners is not a recovery plan.
Decide: support, change workflow, adjust role, or exit
A postmortem should end with one of four decisions.
Continue with added support. Use this when the AI Builder's direction is sound, but the company failed to provide a business owner, permissions, users, or engineering support.
Change the first workflow. Use this when the person shows reasonable judgment, but the original workflow is too broad, sensitive, low-frequency, or technically blocked. Define a new two-to-four-week evidence target.
Adjust the role. Use this when the person is strong in one part of the work but not matched to the original role. They may be useful for low-code operations automation but not as a founding AI Builder. They may be strong in prototypes but not production ownership. They may be strong in business process mapping but not independent integration. Only adjust the role if there is a real business need, not as a way to avoid a hard decision.
Exit. Use this when the company has provided reasonable conditions and the AI Builder still lacks the core capabilities the role requires, or when they show serious risk-boundary problems. Follow your company's HR, legal, and compliance process. Keep records tied to job-related evidence, not personality impressions or irrelevant characteristics.
Ending the relationship is not automatically a failed postmortem. Continuing without evidence is worse.
Keep a decision record
Close the postmortem with one page:
AI Builder:
Original role and first workflow:
Specific symptoms of weak progress:
Confirmed candidate-fit issues:
Confirmed company-support issues:
Data, permission, or system blockers:
Business owner status:
Risk boundaries followed or violated:
Verifiable progress from the last two weeks:
Decision: continue / recovery / change workflow / adjust role / exit
Reason for the decision:
Support the company must provide:
Evidence the AI Builder must deliver:
Review date and next check date:
This record makes the decision fairer and more useful. It also helps the company diagnose its hiring system. If multiple AI Builder hires fail in the same way, the issue may not be talent supply. It may be role definition, offer alignment, workflow selection, or onboarding design.
The real goal of the postmortem
The goal is not to soften standards. It is to avoid the wrong lesson.
If the company was not ready, fix the business owner, workflow, data access, technical support, and success criteria. Otherwise the next hire will run into the same wall.
If the hire is not matched to the role, make a clear decision. Letting an AI Builder role drift into a long experiment damages the business team's trust in AI work and gives the person unclear feedback.
A useful postmortem turns "this is not working" into a specific conclusion: which workflow failed, which condition was missing, which risk is unacceptable, which capability is unproven, and whether the right next step is support, a narrower workflow, role adjustment, or exit.
Use this guide with your first-90-day AI Builder plan, AI Builder offer alignment checklist, and AI workflow maintenance ownership guide. Hiring does not end at the offer. The postmortem decides whether the company learns from the first 90 days.
Next step
Generate an AI Builder hiring brief