Agent-Run Customer Success: How We Make It Work

An enterprise client sends a new program brief. There is a spreadsheet describing which parts of an email sequence can change, assets to host, branding to preserve, targeting rules, and a few details still arriving in the thread.

I remain the point of contact. But a large part of what happens between that email and a working setup now runs through agents.

I ask Codex, connected to my Gmail, to read the conversation and its source materials. We establish what the client is asking for, inspect the existing setup, follow the relevant runbooks, carry out the authorized work, verify the outputs, and prepare a report I can share with the client. Depending on the work, execution happens in Codex or Claude Code.

That is one entrance. Customers can also submit structured tickets through an API. Monitoring finds problems that nobody has emailed about yet. Scheduled recovery handles known failure conditions.

Together, these make up our customer-success operation.

The useful question is how a request survives all the way through that chain.

What our success team has to deliver

Our enterprise work includes setting up customer programs, adapting integrations, checking generated content, investigating missing outputs, recovering incomplete work, and helping clients understand what is ready.

A single program can involve customer-specific rules, several email slots, a personalized resource page, a seller-facing brief, scoring, hosted assets, and an integration that passes the result to another system.

The client experiences one service. Internally, several things can fail independently.

A page can exist with the wrong branding. A callback can return successfully while carrying an incomplete result. A program can be configured correctly but still lack an asset needed for launch.

Customer success therefore needs access to the operational evidence. It has to connect what was promised with what the customer can actually use.

This is the work I am moving into agents: the investigation, configuration, reconciliation, checking, and reporting around that promise. I still own the relationship, priorities, ambiguous requirements, and approvals.

Three entrances, different levels of autonomy

Email is the relationship entrance. Clients send requirements, questions, corrections, and approvals to my own Gmail. I direct Codex to investigate the relevant thread. It can work with the conversation and the repository context together, instead of making me translate every message into a separate technical brief.

This is an interactive workflow. Connecting an inbox does not mean every incoming message launches work unattended.

The ticket system accepts API requests and support email. An integration posts an issue type and the affected record identifiers through the ticket API. A dedicated email-ingestion path can turn an authorized support message into the same ticket shape.

The email path checks the configured recipient, sender authorization, and mail-authentication results before spending model credits on extraction. It suppresses automated replies and quarantines rejected messages for internal review. The extractor pulls out identifiers and the stated campaign; uncertain classification remains provisional. Failed extraction is recorded rather than treated as a successful diagnosis.

The ticket retains the original message reference and enters the normal creation and triage path. This dedicated intake is separate from the work I ask Codex to do in my own Gmail.

Monitoring is the system entrance. It looks for incomplete work, stuck processing, broken outputs, and failures in the monitoring readers themselves. It can surface a problem before the next customer message.

The three entrances share an operating model, while retaining different permissions and execution paths. A scheduled repair for a known condition has a narrower job than an interactive agent investigating a new request.

Reading the request is part of the work

A client email rarely contains the whole specification.

The current message might say to use the updated template. An earlier message explains which paragraph is personalized. A spreadsheet identifies the editable cells through formatting. An attachment contains the approved asset. Another participant supplies the logo later.

Summarizing only the latest paragraph loses requirements.

Our setup runbook starts by preserving the inputs and extracting an explicit contract: the customer identity, intended audience, required outputs, fixed copy, editable slots, approved assets, and unresolved questions.

The agent then compares that contract with the existing configuration. Reuse is valuable, but it has to be deliberate. A previous program may supply the right email structure and a different program the right page layout. Copying an entire old setup can also copy its assumptions.

In two October setups, the requirements included a five-message nurture sequence, a contact-specific resource hub, a seller playbook, and intelligence and scoring. The source workbook specified different replacement slots across the sequence.

Getting that mapping right was customer-success work. A technically valid paragraph in the wrong position would still fail the client's request.

Runbooks turn experience into repeatable execution

The runbooks contain what earlier incidents taught us to check, and they are part of the session's working input.

For an escalated ticket, both the local worker and the CI runner use the same prompt builder. It inserts the ticket playbook and diagnostic runbook directly into the prompt. Score-related tickets also receive the scoring-review runbook. The session therefore starts with the relevant procedures already present.

Alongside those instructions, it receives the ticket, provisional diagnosis, per-record evidence, previous remediation attempts, and any prior resolutions. It must examine what already failed before choosing another action. The automated diagnosis is explicitly a hypothesis.

That context changes the investigation. A record waiting for the recovery ladder should be left to that ladder. A fallback accepted under the program's policy should not be regenerated merely because a session prefers another answer. An intentionally absent output should not become a defect.

For a new setup, that includes verifying the runtime configuration before processing a sample, checking each promised output, comparing the callback with the final API response, and reading the actual pages. For a ticket, it includes distinguishing an unreceived request from work still processing, an intentional omission, and a genuine defect.

CLIs and scripts make those checks executable. They let the session inspect several levels of the operation before deciding whether a repair is appropriate.

The model interprets the request and assembles the evidence. Deterministic checks handle properties we can specify exactly: required fields, mappings, URL presence, asset loading, and agreement between outputs.

When the investigation exposes a repeatable lesson, the ticket playbook requires the session to say whether the runbook needs an update and include that update with the proposed correction. The next session inherits the revised procedure.

This reduces dependence on one long conversation. The next session begins from the current contract, configuration, runbook, and evidence.

One September runbook entry records a new organization and program reaching a finished setup report in one working session, compared with roughly two days each for two earlier setups. That is a useful practitioner observation, with different work in each case. It is not a controlled turnaround benchmark.

The operational lesson is the sequence: preserve the inputs, define the contract, reuse verified components, test the setup, and report the result.

The CLI checks the operation at several levels

Our operator CLI separates inspection from repair. Its commands are read-only; remediation remains in separate, reviewed procedures.

For example, these are inspection commands, not repair commands:

npx tsx scripts/ops/pv.ts lead LEAD_ID
npx tsx scripts/ops/pv.ts campaign CAMPAIGN_ID
npx tsx scripts/ops/pv.ts limits
npx tsx scripts/ops/pv.ts report --since=7d
npx tsx scripts/ops/pv.ts doctor

The CLI shares important predicates with scheduled monitoring. That reduces the chance that a session and a background job invent different definitions of the same fault.

Counting commands validate their readers against controls. The general exit-code contract distinguishes clean results, findings, broken readers, and usage errors. A report with no snapshots in its window is a reader/data-availability problem, not evidence that everything was healthy.

Separate scripts examine configuration, delivered completeness, callback payloads, template assets, and population-wide coverage. The pre-traffic runbook adds infrastructure, credits, dead-letter queues, endpoint reachability, and a controlled end-to-end sample. Together, these let a session move from one reported symptom to the relevant scope of impact.

Guidelines steer judgment; guardrails constrain the result

Runbooks describe the procedure. Guidelines describe how to make the customer-specific decisions inside it: approved terminology, brand voice, offer framing, audience assumptions, factual standards, and the treatment of uncertain information.

Our quality baseline separates shared platform behavior, organization-wide rules, and individual program requirements. Generators load the configured guidelines for their task and program. Where shared email-framework composition is wired in, the framework and program instructions are combined; other engines retain their own loading paths.

The scope matters. We found brief-and-scoring instructions reaching email-paragraph prompts. Those instructions asked for analytical facts and formats that contradicted the email's requirements. The correction was to attach the appropriate instructions to that output.

Guardrails operate at specific boundaries. The controls include:

• Identity and claims: check employer confidence, unsupported company figures, placeholders, prohibited phrases, and unusable text. Some quality gates are enabled by surface and rollout setting.
• Rendering and output: normalize structured values before display, hide empty sections, and enforce surface-specific requirements. Model self-review and a domain-expert read add checks that fixed rules cannot supply.
• Agent authority: treat customer notes and evidence bundles as data, not instructions. The CI runner's AWS diagnostics role is read-only; application credentials and the optional local runner have separately managed boundaries.
• Actions and delivery: keep inspection separate from repair, limit attempts and spend, respect withheld or policy-accepted states, and read back customer-visible writes.

A prompt can explain a rule. Authorization checks, deterministic validation, and credential scope provide different forms of control. I need to know which one is actually in place for the action being taken.

Our 15-minute jobs check different kinds of health

The health checker and the auto-recovery handler are scheduled every 15 minutes. Ticket advancement runs separately, every two minutes.

The health job combines several kinds of evidence:

• Handler errors, timeouts, authentication failures, credit exhaustion, and circuit-breaker signals.
• Workflow backlog: pending outputs, enrichment errors, stuck claims, and abandoned recovery markers.
• Content-integrity signals: empty paragraphs, fallback usage, placeholder leaks, incomplete outputs, and work requiring a person.
• Current stored state, including a bounded sample of recent records whose URL fields may remain broken.
• The health of its own readers and its heartbeat.

The scope differs by check. A log counter describes events in a window. A backlog is a standing total. A sampled record check covers only the records it actually read. The alert wording preserves those distinctions.

Alerts also identify whether a person must act and the first concrete step. Fingerprinting suppresses repeated unchanged alerts, while a separate daily digest summarizes a longer window.

The recovery job acts on eligible cases under its own limits. A health warning does not itself authorize an arbitrary repair.

Monitoring has to inspect the unfinished work

Logs tell us that an event happened. Customer success also needs to know what remains wrong.

One incident exposed this distinction. Records retained placeholder values in customer-facing URL fields after the original write failure had disappeared from the recent log window. Monitoring the error event alone could go quiet while the broken state persisted.

The health checker now includes readers that inspect stored state alongside logs and the workflow journal. The result carries information about whether those readers could actually perform their checks.

That last detail matters. An empty result from a broken reader cannot justify a healthy verdict.

The monitor also publishes a heartbeat. Its own disappearance needs to become visible. In CloudWatch, the treatment of missing data is an explicit alarm setting; AWS documents why that setting depends on the metric's meaning. A missing expected heartbeat and an absent error event mean different things.

A health review completed on October 12 captured 194 health reports in its fixed 48-hour window: 193 green and one warning. It also found zero timestamped inbound submissions during that window.

Both facts belonged in the report. The monitoring had run; the quiet interval had not exercised the complete new-request processing path. Historical exceptions were listed separately.

That is the kind of qualification an agent has to preserve when it turns system evidence into a customer-facing statement.

Self-healing needs a known repair and a stopping point

Our recovery machinery addresses known failure classes. The useful unit is a specific missing or broken output, with a defined remediation and a way to check whether the repair worked.

Before retrying, the system needs to distinguish several conditions. Did we receive the original request? Is processing still underway? Does this program promise the missing output? Was the output intentionally withheld? Is there a safe repair for this failure?

Without those distinctions, recovery can create extra work or damage a healthy result.

A historical incident did exactly that: regenerating a partially complete record lost previously good content when the new generation aborted. Repeating the whole process was a poor substitute for diagnosing the gap.

The controls include limited attempts, paced execution, small pilots, checks on available resources, and escalation when the condition cannot be repaired within the permitted scope. The general reliability principle is well established: AWS recommends bounded retries with backoff and jitter.

The recovery procedures also distinguish restoring existing work from generating new work. The runbook tells sessions to look for an existing artifact or a journaled delivered value first. Regeneration has cost and can change otherwise good content.

Pending delivery, missing outputs, and parked work have different paths. Per-record state, claim controls, pacing, attempt budgets, and run caps keep those paths from racing or retrying indefinitely. Exhausted or unsafe cases move to human attention.

Scheduled recovery and ticket processing have separate controls. Ticket intake, allowed remediation types, system-generated intake, and escalation are independently gated. Their deployed settings determine what runs automatically.

I treat unfamiliar failures as investigations. An agent can assemble the diagnosis and recommend a next action; authority to change production remains tied to the specific workflow and authorization.

A ticket can start a Claude session

The ticket state machine gathers evidence, classifies the problem, and chooses the applicable next state. An eligible issue can enter a bounded remediation-and-verification path. An unresolved issue can move to escalation or human attention.

When escalation is enabled and the runner's gates allow it, the system can dispatch a Claude Code session for that ticket. There is an optional local queue worker and a CI route. Both build the session input from the same playbook, runbooks, and evidence bundle.

The session can investigate a structural fault and return a proposed correction for review, or a written finding explaining why an implementation change is unwarranted. It must support the conclusion with evidence and account for prior attempts.

This is a customer-service escalation into a focused investigation. It does not grant the session permission to replay production remediation or promote its own change.

The distinction matters operationally: the two-minute tick advances the ticket; the Claude session reasons about a difficult case; the recovery job carries out its own eligible repairs. Each has a different responsibility.

A checked-in flag or an old operations guide cannot establish today's deployed configuration. The system has these paths, while activation, credentials, and approval boundaries determine which are available in a given environment.

Closing the loop means checking what the client receives

An older support case generated six rounds of email over about two weeks. We would address the reported symptom, then hear about another missing output that we had not checked.

The investigation needed to cover the program's complete contract.

That experience changed what a resolution has to prove. We inspect the required stored outputs, the customer-facing API, the served pages, and the callback where it is part of the integration. We also account for intentional omissions.

For the two October setups, each report documented three synthetic QA contacts, fifteen reviewed nurture paragraphs, and six sample page URLs. The pages were checked at a 390-pixel viewport. Corrected callback payloads were compared with the final API output.

These were pilot checks, not acquired prospects or a live send.

One program's October 19 setup report recorded campaign processing as active. The other remained held for two missing webinar URLs. Completed samples did not remove that dependency.

The distinction travels into the client report. It explains what was completed, what was verified, which links the client should review, and what still requires their input or their delivery partner's action.

A technically detailed report can still fail if the recipient cannot tell what to do next. I use the agent to gather the evidence, then keep the client message focused on the client's responsibility and decision.

Sending is a separate authorized action. When I ask the assistant to send, it uses the intended thread and recipients, and we verify the sent message afterward.

The scale we can substantiate

The October 6 coverage audit gives a concrete view of the operational estate. It reconciled campaign configuration, templates, stored links, and publicly served pages.

Those figures are a dated audit, not today's totals or a throughput benchmark. The three inaccessible pages remain exceptions to rendered verification.

The important capability is population-level checking. An agent can coordinate an inventory, compare sources, identify exceptions, and prepare a report without making me open thousands of pages manually. Deterministic readers and checks do much of the work.

Capacity also depends on the work being requested. A read-only audit, a new customer setup, and a batch requiring enrichment and generation have different costs and bottlenecks.

Reusable configuration, shared customer context, paced queues, targeted recovery, and explicit exception handling are how we increase the work the operation can handle. More simultaneous model calls alone do not establish more usable output.

What I still need to measure

I can show the setups, outputs, monitoring records, and coverage audits. I do not yet have a reconciled service-wide dataset that establishes a general resolution-time improvement, self-healing rate, cost per resolved request, or human hours saved.

Those require a consistent denominator and a fixed period.

The next scorecard should track unique requests by channel; median and p95 time to diagnosis and verified resolution; eligible failures and successful automatic recoveries; reopened cases; human intervention time; and total operating cost per completed request.

Onboarding needs its own measure, from sufficient client inputs to a verified handoff. Sustainable capacity needs a stated workload and quality threshold.

A hundred checks, a repaired record, and a satisfied customer are different units. Keeping them separate makes the numbers useful.

My role in an agent-run team

I still decide what we promise, which ambiguity needs a client conversation, what deserves priority, and which actions require approval. I review exceptions and make sure the report answers the question the client actually asked.

The agents take on more of the work between those decisions: reading the history, inspecting configuration, following procedures, executing scoped actions, checking outputs, and assembling evidence.

The title describes that division of work. Some paths are scheduled and bounded; others are interactive sessions I direct. The shared discipline is that customer context survives the handoff and completion requires evidence.

When the next client email arrives, the operation has a place to start: the relationship history, the current contract, the last verified state, and the runbook.

The client receives a working result, a clear account of what we checked, and an understandable next step. That is the standard I want the agents to help us maintain as the work grows.

Evidence note: examples are anonymized. Operational figures describe an October 6, 2026 coverage audit, an October 10–12 monitoring window, and October 19 setup reports. Pilot contacts were synthetic. Illustrations explain the operating model and are not screenshots of live systems. These observations do not establish service-wide turnaround, cost, or autonomous resolution rates.