A payroll tax question is never casual. Behind it sits a government agency, a deadline, a penalty, and money that already left the bank. As the legacy assistant wound down, its years of hand-built payroll help couldn't be copied into the agentic platform as scripts, because the diagnosis lived in experts' heads. I drove the sprint that got it out: golden guidance for every priority payroll question in about ten days, two generators that drafted the answers and the full diagnostic reasoning, and the UAT that graded how the real skills behaved against it.
Payroll's most anxious questions got generic answers; the expert diagnosis lived only in people's heads.
Drove the sprint and authored the framework and both generators that turned expert diagnosis into agent-ready ground truth.
Guidance for every priority question in about ten days; one diagnostic set mapped 21 questions to 142 root causes and 78 handoff triggers.
The ground truth, the UAT, and the fix list. The agent team built and ran the skills.
A customer setting up payroll taxes asks for help, and the answer is a map of the settings: correct for every company, specific to none. Whether this customer's federal setup is done, which state forms are missing, what's blocking automatic payments: the system can read all of it, and the answer touches none of it.
The legacy assistant, for all its NLU-era limits, had something these answers didn't: years of hand-built flows that walked payroll customers through their specific situation. When that surface wound down, the flows couldn't move. What could move was what an expert checks before answering.
I'd spent years building NLU-era help like this, and I knew exactly what those flows were: pre-scripted paths, one per situation we'd thought of, each hand-maintained as tax rules and product screens changed. That architecture can't be pasted into an agentic system, and shouldn't be. An agent doesn't follow a path; it decides one. What it needs isn't the script but the judgment the script encoded: what to check, in what order, what the findings mean, and when to stop.
Anticipate the situation, script the steps, maintain every branch by hand. That era is its own case.
The model plans its own path. The design material becomes ground truth: what to retrieve, how to reason over it, what a right answer contains.
What the system checks before speaking, what it must ask instead of guess, and which findings mean a person takes over.
Payroll troubleshooting depends on institutional knowledge the model can't safely infer: which of three settings silently blocks automatic payments, which state rejects which account-number format, what a stuck filing looks like versus a normal one. So I ran a sprint to extract it. Design, payroll product and agent partners, content, engineering, policy, support, and the domain experts themselves, all pulling the same direction. The experts brought the answers and the validation. I brought the structure that made their knowledge usable, and we delivered guidance for every priority question in about ten days.
# what every sprint question had to leave with golden_answer: # what good looks like, written with the experts expected_behavior: # what the agent checks first tool_requirements: # the account data the answer depends on diagnostic_path: # how an expert narrows the cause handoff_boundary: # the point where a person takes over
The golden answers didn't start from blank pages. Hand-authoring exemplars for the top payroll topics would have taken weeks of cross-functional work, so I built a generator to pre-fill them, with payroll experts reviewing every draft. That created a design problem more interesting than the speed: a golden answer sets the bar for how the agent should respond, so the generator had to embody the agent the team envisioned. The vision documents described that agent in deliberately vivid language, and I kept the language, because identity is a behavioral instruction. A model told it's a generic support agent writes like the help center. A model told it sees the whole account and guards a business owner's peace of mind reads the account before it answers.
You are not a chatbot. You are the Supreme Strategic Conductor: a superlative advisor possessing Total Situational Awareness. You don't process tickets; you discern the reality behind the wall. You sit at the intersection of high-compliance precision and radical human empathy, the ultimate guardian of a business owner's peace of mind. You CAN access QuickBooks data. Never say "I can't access your account." You have X-Ray Vision.
The prompt defines failure the same way: not as rules broken but as violations of who the agent is, because a pressured model rationalizes its way around a rule sooner than around an identity.
Asking the customer for data the system can already see. The gap the before-screenshots above fell into.
Giving how-to steps before the customer answers a branching question: W-2 or contractor, existing state or new.
Defaulting to robotic checklists that ignore what's actually happening to the person asking.
The difference is easiest to see side by side. Same question, two identities.
To add a new employee, go to Payroll, then Employees, then Add an Employee. Enter their information and click Save. Let me know if you have other questions.
Documentation, recited. Nothing checks the account, nothing asks which path, nothing explains the stakes.
Exciting, growing the team! I can see you're an Admin on Premium Payroll with employees in CA and TX. One quick question before the steps: will this employee work in California, Texas, or a different state? I ask because if it's a new state, we need to register for state taxes there before running their first paycheck.
Context checked, gate held, stakes explained. That behavior became the golden answers' standard: never give steps before the path is known.
Expert review proved its worth immediately: an early AI-drafted pass claimed QuickBooks Online Payroll caps how many employees you can add. It doesn't. A payroll expert caught the invented fact, and the correction became a permanent line in the prompt. And when the prompt had to shrink to fit limits, the identity language was the last thing I'd cut: a compressed version that opened with a plain payroll-expert identity made every response competent and generic again.
The sprint covered what customers ask. Troubleshooting territories, why a debit failed, why a state isn't being paid, why a filing sits unaccepted, needed full diagnostic reasoning, jurisdiction by jurisdiction. Writing those by hand doesn't scale, and asking tax experts to author decision trees from blank pages is a bad use of scarce experts. So I wrote a generator that turns one customer question into a complete diagnostic worksheet in twelve required sections, from scope and sub-variants through the decision tree down to root causes and handoff triggers. The instruction I cared most about sits at the top: these are not FAQ answers. Each output has to let an agent systematically find the root cause, decide what to retrieve versus what to ask, and resolve or escalate. Experts corrected drafts instead of authoring from scratch, which is the difference between a review meeting and a research project.
"Why is QuickBooks not paying my CA taxes automatically?"
Critical understanding: automatic California payments need three things at once: the EDD account number entered, the power of attorney signed, and automated taxes switched on. Missing any one silently blocks all of it, with no obvious error anywhere.
One troubleshooting set built this way covered 21 diagnostics, 142 catalogued root causes, and 78 handoff triggers, each trigger naming the condition that ends self-serve and what to gather before the handoff. That's the scale argument: judgment stays with experts, volume goes to the machine.
Every diagnostic separates the data the system can retrieve from the information it must ask the customer, and that split is the character of the agent. Ask for something the system can plainly see, and trust drops; the agent feels like the settings page with extra steps. Guess at something only the customer knows, and the answer is dangerous. So the boundary is explicit, per question, and every must-ask carries a documented reason the system can't know it.
"Do you have your CA EDD account number?"
Asked only if the field is empty. The system can see it's missing; it can't know the number.
"Did someone recently change your payroll settings?"
A previous admin or an accountant may have made changes no reachable audit trail shows.
"Will you keep having employees work in California?"
Asked only if no CA employees are found. Intent decides everything downstream: set CA up properly, or close the account.
By April the payroll tax skills were live in Intuit Intelligence, and I ran UAT against them: thirteen cases across four phases, discovery, cross-skill handoffs, bug validation, and guardrails. I graded eleven runs: three passed clean, five came back partial, three failed. Each miss got a diagnosis and the response I'd have wanted instead. Polish wasn't the bar. The bar was whether the agent used the right data, brought in the adjacent skill when the question crossed domains, and answered like it knew what day it was.
| customer asks | skills | grade | what happened | the ideal I wrote |
|---|---|---|---|---|
| "Was my Q1 filing accepted, and did the payment go through?" | filings + payments | partial | The cross-skill handoff worked, but a Form 941 sitting "Submitted" for weeks got called common and reassuring, and the answer was federal-only for a customer with state obligations. | Time-aware and two-sided: flag the elapsed time against the usual 5-to-7-day acceptance, then offer the state filings unprompted. |
| "I see a debit on my bank statement but no payment to the agency. What happened?" | debits + payments | partial | Pulled real data but explained only the debit side, never the payment the customer was worried about, across fifteen months of history for one recent charge. | A narrow window, then each debit matched to its payment record, shown as pairs: what left your bank, and where it went. |
| "What are my state payroll tax liabilities?" | payments | fail | A multi-state company got an answer for California only, silently. The agent knew the other states from its own earlier tool calls; the stale 2024 disclaimer appeared on live data. | Treat "state" as ambiguous: pull every state and summarize, or ask which one, naming the states it already knows. |
| "What were my 2023 payroll tax payments?" | guardrail test | fail | The skills carry a pre-2025 boundary, and the agent bypassed it: queried 2023, found nothing, explained why. A failed guardrail and, awkwardly, a helpful answer. I flagged the bypass and raised the real question: should this guardrail soften? | Enforce the boundary without losing the help: records start in late 2024, there's no 2023 data, here's how to see 2025 onward. |
The misses shared a pattern: the skills retrieved well and reasoned thinly. Time-blindness, one-sided cross-skill answers, disclaimers contradicting live data, date ranges wider than the question. Every one became a documented issue with the wanted response attached, so the fix had a target. Here's a graded run in full.
Guidance for every priority question by early February, plus the diagnostic layer for the troubleshooting territories: worksheets an agent can follow and an eval can check.
Nine troubleshooting territories carried expert validation. The generator drafted; the tax experts confirmed and corrected.
UAT closed with a recommendations sheet, each item mapped to the skill prompt that needed it: a mandatory pre-answer checklist for the automation question, disambiguation rules for multi-state companies, a translation table for internal status codes, and a time-aware check for stuck filings.
The agent team built and ran the skills. The ground truth they built against, the UAT that graded the results, and the fix list that came out of it are the work on this page.
And the target behavior is real. Here's the setup question from the top of this page, answered the way the ground truth says it should be: from this company's account, naming exactly which federal and California steps remain.
Payroll changed what I think the design job is. The design surface isn't the dialog anymore. It's what the system checks before it speaks and what a right answer has to contain. Producing that at expert quality and machine volume is the job now, and the grading discipline behind it was built in the quality program.