Context Engineering With Google ADK: State and Retrieval

Context engineering with Google ADK means choosing the instructions, working state, retrieved evidence, and tools an agent needs for its current task. ADK, the Agent Development Kit, provides application building blocks; you still decide what information the model should receive. A shared record such as fenbs can keep approved project decisions and progress available to supported connected assistants.

Start by separating two meanings of context. ADK context objects help application code reach state and services. The model’s context is the material actually sent for an answer. Access to a value in your program does not mean that the value belongs in every model request.

How do you plan the information before building?

1. Choose one task with an observable result, such as drafting a setup checklist from an approved product guide.
2. List the current request, required sources, continuing project rules, and checks that define success.
3. Assign each input a home: agent instructions, working state, a retrievable source, or a reviewed work record.
4. Define missing-information and approval paths before allowing the agent to make consequential changes.

For a setup checklist, the current product guide is evidence. The customer’s selected configuration is task data. A rule requiring an owner to approve publication is a continuing boundary. Do not flatten these into one summary that loses which statement came from a source and which came from a person’s choice.

For the general reasoning behind this separation, see context engineering for AI agents. This guide focuses on applying it to ADK’s context, state, and retrieval responsibilities.

What does an ADK context object provide?

Google’s agent context documentation↗ (opens in a new tab) describes context objects supplied to agents, tools, and callbacks, which are functions that run around workflow events. These objects give code access to relevant state and services. Use the object intended for the part of the workflow you are writing rather than passing unrelated application details everywhere.

Keep model-facing instructions focused on the job. Internal service configuration, operational identifiers, and other users’ information should not enter a prompt merely because code can access them. Build the model input deliberately and enforce access in the service or application, outside the model’s judgment.

Write down the distinction during review: what can the tool read, what does it return, and which part of that result reaches the model? A correct tool can still produce an unsuitable model input if its full response contains irrelevant or overly broad information.

Which values belong in session state?

Use state for values needed to continue the task: the selected document, current stage, outstanding question, or review result. ADK’s state guide↗ (opens in a new tab) explains session values and the user, application, and temporary scopes identified by key prefixes. The persistence service also matters; a name alone does not establish that data survives a restart.

Treat that table as a design aid, not a storage prescription. Choose scope from your actual access and retention requirements. A project approval is not an application-wide setting merely because several sessions need it. Keep its project identity, status, and source intact wherever you store it.

For human-approved project rules, fenbs keeps a record in Decisions and rules. That record can inform development work without pretending to replace the state service inside your ADK application.

When should the agent retrieve information?

Retrieve information when the next answer depends on evidence outside the current task input. Ask a narrow question, such as which setup steps apply to the chosen configuration. Return the relevant passage with its source and status. Avoid delivering a collection of unrelated matches and expecting the model to infer what governs.

ADK’s memory documentation↗ (opens in a new tab) describes a MemoryService for searchable information beyond one conversation. Decide separately whether you need past conversation material, a current reference document, or an approved decision. Finding a statement in memory does not establish that the statement remains true or was ever approved.

Preserve a clear failure result. No matching source, denied access, and an unavailable service are different conditions. The agent should ask for the missing evidence or explain the access problem. It should not treat a failed lookup as permission to invent a setup step. For development handoffs, fenbs keeps current project context, including outstanding checks, available to supported connected assistants.

How should external tools supply project context?

Google documents MCP tools in ADK↗ (opens in a new tab), including importing external tools through a toolset. MCP is a standard way for AI apps to use outside tools. Support for that standard is a useful building block, but it does not by itself verify that a particular server’s transport, authentication, and access behavior work in your application.

fenbs does not provide a ready-made Google ADK integration or SDK. Its supported AI client connections are listed in integrations. A custom ADK connection to fenbs would require integration work and testing, including compatible browser sign-in, readable permission refusals, and appropriate handling of writes.

You can start without building that connection: use a supported assistant to read the project record while helping you develop the ADK workflow. For a different application framework, the LangChain guide owns that implementation path. For work inside an existing development tool, see context in Cursor.

How to do this with fenbs

1. Create a free account and add the project for your ADK workflow.
2. Create a task with a plan describing input selection, state scope, sources, and acceptance checks.
3. Record the boundaries a person approved in Decisions and rules; keep unapproved proposals labeled separately.
4. Use a supported connected assistant to read project context before work, then save progress and the remaining checks in Where we left off.

fenbs is not the right fit for running ADK agents, implementing MemoryService, or supplying a search index. It is useful when the team building those systems needs a shared account of what was decided and what still needs attention.

How do you verify the state and retrieval boundaries?

Run a task with a known source and inspect the assembled model input. Then test a missing source, a conflicting draft, and a session that resumes after interruption. Check which values survive and whether another user or unrelated task could receive them. A plausible answer is insufficient evidence that the scope is correct.

Keep the failing example with its expected behavior. Change one boundary at a time, then rerun the same example. The context engineering hub collects related methods; your practical checkpoint is that you can explain where each important fact came from and why this task can use it.