Report Generation from Context — Four Account Documents from One File

Published

Project article; see sources and editorial standards.

I built a generator that turns a customer context file, plus live account data, into the four documents a technical account manager (TAM) keeps for an account: an Account Review, a TAM Support Plan, a TAM Engagement Overview and a Joint Incident Management Plan. The demo produced all four, alongside a reviewers’ guide. The documents are customer deliverables, so this post does not include them. It describes the pipeline and what each document contains.

The generator is a Claude Code skill: a written specification that an agent follows, calling tools over the Model Context Protocol (MCP) to fetch data. Its rules are instructions to that agent, not code that enforces them. This post rests on the specification and the document templates, not on a measured run, and it reports no timings or quality scores.

Where the context file fits

A customer context file is one markdown document per account. A separate consolidation step builds it from the local files I have gathered for that customer. The generator reads it first and takes the account team, the customer contacts, the security constraints and an architecture summary from it. The templates mark judgment content as manual entry, such as risk assessments, leadership asks, plans, outcome definitions, constraints and open questions. The generator fills those fields from the file, or flags the gap instead of guessing.

For these four document types, the context file does not replace live data. Open cases, ticket chains and cluster state come from calls made during the run. (The weekly update follows different source rules and is outside this post.)

The generator checks the file’s age before it trusts it. A file up to 24 hours old is used directly. A file 24 to 72 hours old is used, and the generation summary records its age. A file older than 72 hours, or one with no as-of date, is refused: the generator falls back to live sources and recommends rebuilding the file.

The six phases

Every run takes two required inputs, the account name and the document type, plus an as-of date that defaults to today. If the account name matches more than one account, the generator asks one clarifying question. The phases then run in strict order, and by default none is skipped.

  1. Resolve. Normalize the account name and read the context file.
  2. Collect. Call up to six sources in parallel: the case assistant, the TAM account-context store, Glean (for Salesforce commercial data and Jira HELP tickets), Slack, monday.com boards and MongoDB (Atlas cluster data and a synced Slack store). The specification marks the first three as required and the others as optional, and each document type adds its own list of needed sources. A run is capped at 40 calls, spent on required sources first, and a source that fails with a timeout or server error is retried once.
  3. Template. Fill the document type’s template from the collected data.
  4. Enrich. Add Slack signals to the risk and next-step sections. Check that case IDs are still current, team members are still on the roster and no initiative date has passed without an update. Compute derived figures such as case frequency, severity-1 and severity-2 (S1 and S2) concentration, backup coverage, multi-region share and version adoption.
  5. Validate. Run a checklist before delivery: zero unfilled placeholders, case IDs verified against live data, absolute dates, an as-of date that matches the request, the expected section count, a source annotation on every claim, none of eight banned AI-sounding words, and an executive summary that matches the body.
  6. Output. Write the document to the account’s folder and report a generation summary: sources queried, sources that failed, the count of unavailable-data markers, and the word and section counts.

A separate collector can run first. It gathers cases, Salesforce data, infrastructure data, HELP tickets, Slack activity and initiatives in parallel, writes each result to disk as timestamped JSON, and records per-source timestamps and errors in a manifest. The specification tells the generator to read those files, when they are under an hour old, before making duplicate calls.

The templates

Each document type has a reconstruction-prompt template: a prompt with placeholders from which an agent rebuilds the document. I derived each one from an existing finished document with a deconstruction step. The Engagement Overview and Incident Management Plan templates keep their static methodology text verbatim and change only the placeholders. Each template includes a data-dependency table that maps every placeholder to a source (case data, the TAM account-context store, Glean, Atlas metrics, monday.com, Slack, a derived value or manual entry) and an extraction method. If a document type has no template, the generator falls back to a master template.

Rules the generator follows

What each document contains

Account Review. A leadership readout, used quarterly or ad hoc. It opens with a header (as-of date, author, audience, status) and a one-paragraph executive summary. The body covers case history (twelve-month volume, open cases, the chain of HELP tickets, trends), projects and apps, the MongoDB inventory, product usage, data trends, the customer team profile and customer plans. It then gives a health check, a technical scoreboard, a risk analysis, leadership asks, internal stakeholders and a summary of the initiative board. A closing Missing Fields table lists what the generator could not source and where to find it.

TAM Support Plan. The planning document, used annually or twice a year. It holds the account team, planned duration, customer outcomes, blockers, known risks, initiatives, metrics and reporting, a communication plan and a change history. The template’s notes set three consistency rules: outcomes and initiatives map many-to-many, every metric traces to at least one initiative and one outcome, and a blocker’s target date falls before the date of the initiative it gates. Blockers and risks change weekly, so the notes call for refreshing them from the latest snapshot and case status before each regeneration.

TAM Engagement Overview. The document for onboarding, handoff and reference, written so an incoming TAM can pick up the account from it. It covers scope and current state, the service architecture and Atlas cluster inventory, priority clusters, current initiatives, open issues, the working model, support goals, issue handling, incident protocol, communication channels, the technical team and the account team, security constraints, near-term next steps, open questions and a stakeholder appendix. The methodology sections, such as support goals and incident protocol, are static. The inventory, priority clusters, initiatives, issues, constraints and next steps are account-specific.

Joint Incident Management Plan. The incident-readiness document, written to print as a standalone reference. It covers severity mapping with response targets and update cadence, the definition of an S1, current incident context, team roles, the roster of directly responsible individuals (DRIs), the bridge contact path, break-glass authorization, required information at incident creation, response methodology, resolution criteria, retrospective timing, communication channels and an escalation matrix. Template emails and an acronym list follow. The plan carries a draft or ratified state, and a draft caveat appears only while it is a draft. Customer-side contacts and ratification are manual-entry fields because a person has to confirm them.

What the checks cover

The generator’s success criteria check form: placeholders filled, case IDs verified, the right date, and every source listed with a pass or fail. They do not measure whether an analysis is good, and this post makes no claim about that.