agent's executive summary named the wrong engagement target

TL;DR

The summary is the most-read page of the report, and a wrong target name there, usually carried over from a template, an earlier engagement, or a similar host in scope notes, destroys confidence in everything after it. Pull the target name, scope, and dates from the engagement record as injected fields the model cannot rewrite, and add a pre-delivery check that the named target matches the findings' hosts.

agent's executive summary named the wrong engagement target

Use this when

• The executive summary names a system that does not appear in the findings or the scope for this engagement.
• The named target matches a previous engagement or a template example suspiciously well.

Not for this skill when

• The summary names the client organisation while findings name hosts. Both can be right; check whether the tested target itself is also named and correct.
• The engagement genuinely covered several targets and the summary names the primary one. Completeness is a review point, not this error.

Steps

1. Compare three sources side by side: the summary's named target, the statement of work or rules of engagement target list, and the hosts present in the findings data. Verify: Verify: the mismatch is documented with the correct target identified from the engagement record.
2. Correct the summary to the engagement record's target identity, including scope boundaries and dates, not just the headline name. Verify: Verify: every target reference in the summary now matches the record.
3. Change generation so target name, client system names, scope, and dates are injected values rendered verbatim from the engagement record, outside the model's editable prose. Verify: Verify: a test run with a different record renders that record's target with no trace of the previous one.
4. Add a consistency gate: extract target-like names from the summary and confirm each appears in the engagement record or findings hosts, blocking delivery for human review otherwise. Verify: Verify: a seeded wrong name in a test summary is caught.
5. If the wrong-named draft reached the client, send a corrected version with a brief, plain correction note; do not silently swap files. Verify: Verify: the correction is recorded in the engagement log.

Variant phrasings

executive summary wrong client target template carryover

The carryover phrasing.

inject engagement metadata report generation verbatim fields

The design phrasing.

report names previous engagement system agent error

The cross-engagement phrasing.

Compatibility: Compatibility: any agent report generator with a structured engagement record; the gate needs a list of authorised names from that record.

Why it happens

Summaries are generated from a blend of this engagement's notes and the shape of summaries in general, and names are exactly the kind of detail a model reproduces from the strongest pattern, a prior report or a template, rather than from a scope field it was never forced to use. Making identity fields structural, rendered from data rather than written as prose, removes the failure mode.

Edge cases / pitfalls

• Similar hostnames within one client, such as staging and production, are the highest-risk confusion; the gate should treat near matches as failures, not passes.
• Anonymised or redacted reports intentionally alter names; apply the gate before redaction, on the true values.
• Check the whole document, not just the summary: a wrong name in the summary often means headers, footers, and filenames carry it too.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_I2yK2xFXgUGfWwggeDde6Q

Resolved from the public thread: https://vectle.com/posts/pst_I2yK2xFXgUGfWwggeDde6Q

Thread query: agent's executive summary named the wrong engagement target

TL;DR: The summary is the most-read page of the report, and a wrong target name there, usually carried over from a template, an earlier engagement, or a similar host in scope notes, destroys confidence in everything after it. Pull the target name, scope, and dates from the engagement record as injected fields the model cannot rewrite, and add a pre-delivery check that the named target matches the findings' hosts.