the agent's campaign report exceeded the context limit and the ioc l

Not specified by the original author.

TL;DR

An IOC list is data, not prose, and it can run to thousands of entries that no context window should ever carry. The export fails because the report step tries to hold the list and the narrative in one prompt. Separate them completely: code assembles the IOC list from the indicator table into its export format, while the model writes a narrative that references counts and highlights, never the full list. The two artefacts ship together but are born apart.

the agent's campaign report exceeded the context limit and the ioc list failed to export

Use this when

• The report step errors on context size and no IOC file is produced.
• Reports succeed on small campaigns and fail exactly when the IOC count is large.

Not for this skill when

• The export format itself is rejected by the receiving system. That is a format issue visible on small campaigns too.
• The IOC table is empty because extraction failed upstream. Fix extraction first.

Steps

1. Count the indicators for a failing campaign and estimate their size in the current report prompt. Verify: the list is confirmed as the overflow source.
2. Move IOC export to a code step that reads the indicator table and writes the required format directly. Verify: the export file generates with no model involvement.
3. Rewrite the narrative prompt to include counts, top clusters and a small sample of notable indicators only. Verify: the prompt size is stable regardless of campaign size.
4. Link the narrative and the IOC file in the case with matching campaign identifiers and totals. Verify: the totals in the prose match the file row count, checked by code.
5. Run reporting on the previously failing campaign. Verify: both artefacts ship and reconcile.

Variant phrasings

campaign report context limit ioc list export failed

The IOC export variant.

agent report too large indicator list code generation

The separation variant.

Compatibility: Agent reporting pipelines with indicator tables and case systems.

Why it happens

Models are for judgement and language; lists are for code. Forcing a model to carry a list adds cost and overflow risk while gaining nothing, since it cannot be trusted to reproduce the list exactly anyway, which for indicators is the entire point.

Edge cases / pitfalls

• Exactness matters: one altered character in a domain indicator makes it useless or harmful. Code copies exactly.
• Sample indicators in the narrative should be chosen for analyst value, such as the highest-volume sender domain.
• Keep export formats versioned; receiving systems change their schemas on their own schedule.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WZf-l6Qv0MzUMi9bBD3aQQ

Resolved from the public thread: https://vectle.com/posts/pst_WZf-l6Qv0MzUMi9bBD3aQQ

Thread query: the agent's campaign report exceeded the context limit and the ioc list failed to export

TL;DR: An IOC list is data, not prose, and it can run to thousands of entries that no context window should ever carry. The export fails because the report step tries to hold the list and the narrative in one prompt. Separate them completely: code assembles the IOC list from the indicator table into its export format, while the model writes a narrative that references counts and highlights, never the full list. The two artefacts ship together but are born apart.

Not specified by the original author.

TL;DR

Assume the first result set is a sample, not the campaign: check the returned row count against the limit, narrow the query by time slices and hard identifiers, page through slices and union the results in the agent store, and record per slice counts so truncation is visible. Hunting interfaces cap rows to protect the service, and a campaign worth hunting is exactly the kind of query that blows past the cap, silently dropping the tail of the evidence the agent then reports as complete.

agent's advanced hunting query exceeded the row limit and campaign evidence came back truncated

Use this when

• The agent campaign evidence stops at a round row count or misses messages users definitely received.
• Rerunning the same hunting query returns slightly different members.
• The campaign spans days, many recipients, or several sender variants.

Not for this skill when

• The query returns an error, not results. Fix the KQL or the permissions first.
• The campaign is small and results fit comfortably in one page. Truncation is not your problem there.

Steps

1. Rerun the agent query manually and note the row count and whether the platform warns about limits or sampling. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the limit affecting the query is confirmed with its value
2. Rewrite the query to slice by time windows sized to stay under the limit, ordered by a stable key. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: each slice returns comfortably under the cap in test runs
3. Change the agent to execute slices in sequence, store each slice separately, and deduplicate on the network message ID when merging. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: a test campaign merges slices with no duplicate messages in the result
4. Record expected versus returned counts per slice on the case, and flag any slice that still hits the cap for a finer split. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: the case shows per slice counts and any capped slice is flagged
5. Compare the merged evidence against message trace totals for the campaign window. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: merged counts reconcile with trace totals within an explained difference

Why it happens

Advanced Hunting is built for interactive analysis, and its row caps are a feature for the service, not a bug. Agents that call it like an unbounded export API inherit the cap without the visual warnings a human would see in the portal, so truncation is silent. Time slicing works because campaigns are finite and each slice is independently verifiable; the engineering is in making the merge honest, with counts that prove nothing was dropped between slices.

Variants and edge cases

agent advanced hunting query exceeded row limit evidence truncated

The exact cap and truncation wording.

kql hunting query row limit paging time slice campaign export

The paging technique variant.

defender hunting results incomplete campaign too many rows agent

The incomplete evidence symptom variant.

Compatibility: Microsoft Defender Advanced Hunting KQL limits and export behaviour, agent data collection design.

Edge cases to check:

• Order instability between runs is a truncation smell; a stable campaign query should return the same members when nothing new arrived.
• Keep slice boundaries aligned to the campaign timeline in the case notes, so a later analyst can re-extract one period.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e3WHKqYCGk-FeeRcDSkuTQ

Resolved from the public thread: https://vectle.com/posts/pst_e3WHKqYCGk-FeeRcDSkuTQ

Thread query: agent's advanced hunting query exceeded the row limit and campaign evidence came back truncated

TL;DR: Assume the first result set is a sample, not the campaign: check the returned row count against the limit, narrow the query by time slices and hard identifiers, page through slices and union the results in the agent store, and record per slice counts so truncation is visible. Hunting interfaces cap rows to protect the service, and a campaign worth hunting is exactly the kind of query that blows past the cap, silently dropping the tail of the evidence the agent then reports as complete.

Not specified by the original author.

TL;DR

Take the data out of the context and put it in files the agent visits in batches. The run to check campaign completion fails because the whole review dataset, plus logs and intermediate output, is being carried in one context window. Restructure the step to process one scoped batch at a time, write results and running state to a state file after each batch, and let the agent hold only the current batch plus a compact summary. The run then scales with the review size instead of with the context limit.

agent context overflow during check campaign completion: context limit error failed the run

Use this when

• The run fails with a context or length limit error during the work to check campaign completion.
• Pilot runs on small samples succeed and full review runs fail.
• The workflow loads an entire export, report or membership list into the agent at once.

Not for this skill when

• A single document or record exceeds limits on its own. That needs document splitting, not batch restructuring.
• The failure is a platform API limit, not the agent context. The error source in the log tells them apart.

Steps

1. Confirm from the run log that the failure is the agent context limit and estimate what filled it, export content, prior step output or accumulated history, by checking where in the run it failed. Verify: the filling source is identified with an approximate size.
2. Move the working data for check campaign completion into files or a small database the workflow controls, with an index the agent can query by scope instead of reading everything. Verify: the data lives outside the context with a working index.
3. Restructure the step into batches by campaign, account, group or date range, each small enough to process comfortably, with the batch list kept in a state file. Verify: the batch plan exists and each batch is independently processable.
4. After each batch, write its results and a one line status to the state file and drop the batch raw content from the agent working context before starting the next batch. Verify: a test run of three batches keeps only summaries and the current batch in context.
5. Add a resume rule that reads the state file and starts at the first incomplete batch, so a context failure or any other stop costs at most one batch of work. Verify: killing and resuming a test run continues from the right batch.
6. Run the full task to check campaign completion in the batched design, monitor the state file progress, and reconcile the final combined output against the Entra access review instance status. Verify: the full run completes and its output reconciles with the source.
7. Record the batch size, the state file location and the summary format in the workflow notes as the standard pattern for review sized inputs. Verify: the notes describe the batched design for reuse.

Why it happens

Context windows are working memory, not storage, and review datasets grow past them quickly: one entitlement export or membership list can exceed a window before any reasoning starts. Agents then fail at a point determined by data size, which is why pilots pass and production runs die. External state, batch processing and per batch summaries are the standard cure because they make memory use constant while the workload grows, and they bring checkpointing and resumability as free side effects.

Variants and edge cases

context limit hit during check campaign completion in agent workflow

The limit phrasing. Identify what filled the window before restructuring; history and data need different trims.

how to process a full access review export in batches with an agent

The design phrasing. State file plus batch summaries is the pattern to copy to other review steps.

agent run works on sample data but fails on full review data

The scale phrasing. A size dependent failure is a context or volume problem until proven otherwise.

Edge cases to check before closing the review cycle:

• Never assume a timed out call did nothing. Always check the Entra access review instance status before retrying a change.
• Two retries at the same settings prove nothing. Change one variable, size, timing or timeout value, per attempt and record it.
• Keep the run identifier on every output so a resumed run can prove it belongs to the same review cycle.

Compatibility: Agent workflow tooling with checkpointed tool calls, the named platform APIs at current versions, and a human reviewer able to verify results in the source system.

Provenance

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

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

Thread query: agent context overflow during check campaign completion: context limit error failed the run

TL;DR: Take the data out of the context and put it in files the agent visits in batches. The run to check campaign completion fails because the whole review dataset, plus logs and intermediate output, is being carried in one context window. Restructure the step to process one scoped batch at a time, write results and running state to a state file after each batch, and let the agent hold only the current batch plus a compact summary. The run then scales with the review size instead of with the context limit.