What is invocationcontext?

A context object containing the information needed during one agent turn, meaning one cycle of handling a user request. It can include the current session, state, agent, services, runtime settings, and tracking identifiers.

Use it inside agent flows, processors, callbacks, and tools that need session data, configuration, services, logging details, or a signal that the turn should end.

It avoids passing many separate values through every layer of agent processing. This makes access to the current turn's information more consistent.

invocationcontext — Cursor rule for Cursor by altaidevorg/rules-for-ai

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

Clone the repo

git clone --depth 1 https://github.com/altaidevorg/rules-for-ai

Made for: Cursor.

Wrote this? Show the measurements

A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.

README.md

[![agentmods](https://agentmods.dev/badge/rules/altaidevorg/rules-for-ai/invocationcontext/github.svg)](https://agentmods.dev/rules/altaidevorg/rules-for-ai/invocationcontext)

Your own site

<a href="https://agentmods.dev/rules/altaidevorg/rules-for-ai/invocationcontext"><img src="https://agentmods.dev/badge/rules/altaidevorg/rules-for-ai/invocationcontext/github.svg" alt="Measured on agentmods" height="20"></a>

Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.

Your own site · 80×15

<a href="https://agentmods.dev/rules/altaidevorg/rules-for-ai/invocationcontext"><img src="https://agentmods.dev/badge/rules/altaidevorg/rules-for-ai/invocationcontext.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 0 Nothing until a file matches its globs; then the whole rule loads.

When invoked 3,864 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin original No closer match found in the catalogue.

Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

Model	Per session	Once invoked
Fable 5.1	$0.00000	$0.03864
Opus 5.5	$0.00000	$0.01546
Sonnet 5.5	$0.00000	$0.00773
Haiku 4.5	$0.00000	$0.00386

Measured 2mo ago against content hash dd59e3c0e7a3, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

invocationcontext scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

examples/google-adk/invocationcontext.mdc · 288 lines

How it starts

The opening of the file, as written. The whole thing — 288 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Chapter 9: InvocationContext

In the previous chapter, we explored BaseLlmFlow, the engine that orchestrates the complex interaction between an Agent (BaseAgent / LlmAgent) and the BaseLlm, especially when handling Tools (BaseTool). We saw that the flow logic often needs access to the current session, services, agent configuration, and more. Passing all these elements individually down the call stack (Runner -> Agent -> Flow -> Processors -> Callbacks -> Tools) would be cumbersome and error-prone. This chapter introduces InvocationContext, the object designed to solve this by encapsulating all necessary information for a single agent turn (invocation).

Motivation and Use Case

Consider a single turn initiated by a user message. Processing this message might involve:

Retrieving the Session (Session / BaseSessionService) history and State.
Knowing which specific Agent (BaseAgent / LlmAgent) is currently active (especially in hierarchical setups).
Accessing services like artifact_service or session_service.
Applying runtime configurations (RunConfig).
Tracking unique identifiers for logging and tracing.
Signaling when the turn should end prematurely.

Instead of passing numerous parameters through every function call, InvocationContext acts as a "carrier" object. It bundles all this context together and is passed down through the execution hierarchy. This promotes cleaner code, ensures necessary information is available where needed without relying on global state, and simplifies the interfaces of core components like agents, flows, and tools.

Central Use Case: The Runner receives a user message for a specific session.

The Runner creates an InvocationContext instance, populating it with the fetched Session, references to the configured services (session_service, etc.), the root agent, the user_content, a unique invocation_id, and the RunConfig.
The Runner determines the correct agent to run (e.g., agent_A) and calls agent_A.run_async(invocation_context).
Inside agent_A, if it needs to call a sub-agent (agent_B), it creates a new InvocationContext (usually a copy of the parent's, updating agent to agent_B and appending to branch) and calls agent_B.run_async(sub_context).
If agent_B (an LlmAgent) uses its internal BaseLlmFlow, it passes its InvocationContext (sub_context) to the flow.
If the flow triggers a Tool (BaseTool), it creates a ToolContext (which wraps the InvocationContext) and passes it to the tool's run_async.
Throughout this flow, any component (agent, flow, tool, callback) can access, for example, ctx.session.state or ctx.session_service via the context object it received.

Read the full file on GitHub · 288 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

2mo ago First seen · 288 lines · 0 tokens per session scan A dd59e3c0e7a3

Subscribe to this mod's changes

invocationcontext is a cursor rule published in the GitHub repository altaidevorg/rules-for-ai (2 stars, last pushed 1y ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 3,864 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Building agents

invocationcontext

Getting it into your agent

Wrote this? Show the measurements

What it costs to keep this loaded

Grade A, and why

Nothing flagged

How it starts

Chapter 9: InvocationContext

Motivation and Use Case

What this file has done since we first saw it

Other cursor rules, from other repositories

ponytail

angular-20

dev-standard

prefer-direct-imports-over-module-mocks

config-validation-and-normalization

control-plane-descriptors