How do you improve AgentCore performance and usability together?

A chart is already on screen, but the agent keeps reasoning. A long analysis finishes on the server, yet its progress card stops updating after authentication renewal. Repeating a question starts the calculation from scratch. Users experience all three as slowness. Their causes differ.

We encountered these problems while improving a data analysis agent. We had to inspect unnecessary calls after model inference, source collection and checkpoint restoration, and the UI's status polling separately. Amazon Bedrock AgentCore provides an execution environment, sessions, memory, and observability. The application defines what request completion and business state mean.¹

The implementation examples here come from actual code and production measurements recorded on October 13, 2026. The research-document authoring, validation, and approval workflow is a design example generalized from a separate proposal and implementation specification. Its operational outcomes have not been validated. We omit customer identifiers and internal addresses, and explain the principles that transfer between these cases.²

Measure response latency and task completion separately

A quick first token does not end the user's wait if the answer remains incomplete. A lengthy task can still let users move on when acceptance, progress, and a recoverable result are clear. A single performance metric hides that distinction.

Our implementation measured source downloads, decompression, database execution, sample transformation, and checkpoint reads and writes separately. We used those measurements to identify bottlenecks and choose changes. Child timings are included in parent stages, and accumulated durations from parallel calls differ from elapsed time. Adding every line does not produce an accurate end-to-end duration.

AgentCore Observability provides a foundation for tracing model, tool, and agent execution.³ The application connects request IDs, job IDs, stages, outcomes, and applied versions. A session ID alone cannot distinguish multiple questions in one conversation. Preserve these correlations in operational logs without automatically recording raw questions, identifiers, and result data.

Close fast paths only after verifying every required task

Dedicated tools for data queries and chart generation can reduce exploration by a general-purpose agent. A common failure is letting a shortcut answer part of the question and then close the entire request. “Compare last month's values, show two charts, and include the internal criteria” is not complete after returning one number.

Our implementation used a request completion ledger to track independent obligations such as retrieval, attachment review, and chart generation. A model saying it has finished is not execution evidence. Successful tool results and actual artifacts settle each obligation. Two requested charts require two distinct artifacts; refreshing the signed URL of the same image does not create another chart.

After publishing a verified direct result, the orchestrator stops the next model turn if no obligation remains. It continues when internal-source retrieval or interpretation is still required. This condition removes unnecessary calls while guarding against omitted tasks. It also reduces the chance of changing numbers or evidence while restating an already complete answer.

The following pseudocode simplifies the completion decision. It is not an SDK example that can be run unchanged.

required = parse_required_tasks(request)
results = execute_allowed_tools(required, auth_context)
confirmed = verify_tool_results_and_artifacts(results)
remaining = required - confirmed
if remaining:
    continue_or_report_partial(remaining)
else:
    publish_verified_result_and_close()

Model-based intent extraction helps select tools. Code validates authorization, periods, subjects, artifact counts, and completion again. Regression cases check that a total-account-count shortcut does not replace an all-account analysis, and that explaining an attached chart does not become a request to generate a new one.

Finish long analyses outside the conversation

AgentCore Runtime supports asynchronous and long-running execution. The SDK tracks task starts and completions to manage session processing state.⁴ That may be enough for a short background operation. Work that traverses many subjects, retries failed units, and must remain accessible after the browser closes needs a separate job state.

In our analysis implementation, the business API accepts a request and Step Functions Standard launches an ECS Fargate worker. DynamoDB stores job state. S3 preserves inputs, collection manifests, intermediate results, and final artifacts. Conversational requests use AgentCore's streaming path. We do not place every request in one long conversation session.

A job binds its owner, conversation, attempt number, and execution lease. A restarted worker reuses successful units already saved. A worker from an earlier attempt cannot overwrite the current attempt's result if it finishes late. Cancellation and ownership checks run again at persistence and completion boundaries.

The UI exposes QUEUED, RUNNING, COMPLETED, FAILED, and CANCELLED as job states. A failed lookup is not displayed as absent data, and retry and cancel are explicit actions. Keeping analysis conditions and results with the accepted job lets users identify which question a result answers after reopening the conversation.

AgentCore session isolation separates execution environments.⁵ It does not automatically decide who may read a persisted job. Check roles and ownership in job-list, result, and download APIs. Do not use a Runtime session ID as a user-authentication credential.

Separate prompt, intermediate-result, and UI caches

“We added a cache” does not explain what became faster. Our implementation had caches with different purposes and different reuse conditions.

We put stable instructions first and the question, clock, and request context afterward. We separated the reusable prefix and pinned the caching flag in release configuration. Bedrock's supported models, APIs, token minimums, and TTLs differ. Configuration alone does not guarantee a hit. Inspect usage fields for the selected API, such as cacheReadInputTokens and cacheWriteInputTokens, and include cache-write costs when assessing the benefit.⁶

The same worker reused intermediates successfully saved to S3 from a bounded local store. If the local value was missing or corrupt, it recovered from S3. The local cache is an optimization; the persisted checkpoint is the durability boundary. Data that disappears with the process cannot be the only recovery evidence.

The UI cache reduces repeated completed-result fetches and duplicate insertion. Renewing an authentication token in the same conversation does not erase completed answers. Account changes need a separate invalidation boundary and verification. Identical question text does not establish identical authorization or data freshness.

Keep AgentCore Memory distinct from these caches. It stores and retrieves conversation events and longer-term context; the application must integrate recording, retrieval, and use in the current request.⁷ Even when preferences or past conversations are recalled, tools must check current source values and access rights. A remembered answer is not evidence for a fresh analysis.

Distinguish failed lookups from verified empty data

Large analyses spent time querying empty periods repeatedly and rereading the same grouped checkpoints for calculations across subjects. We checked source ranges first and reduced repeated queries for verified empty units. If the range check failed, the existing source query continued. Lookup errors were not converted into empty data.

We also reduced remote round trips for ownership checks. Calls within the loop were rate-limited, while actual source reads, persistence, progress updates, and completion boundaries forced a fresh check. We did not gain speed by removing those checks. We verified that late results from cancelled jobs were not published.

These are observations from rerunning the same questions in production on October 13, 2026. Workers used 2 vCPU and 8 GiB before and after the changes.⁸

Checkpoint restoration and per-subject calculation fell from 89 to 20 seconds and from 198 to 49 seconds, respectively. Source collection still dominated at 437 and 750 seconds. Some accumulated decompression and transformation timings increased. A lower overall duration does not mean every stage improved.

Active subjects and source data changed during measurement. These results are not a controlled A/B experiment, p95 measurement, or SLA. The 271-day range is not a full calendar year. We excluded the longer range's first-visible-result timing because authentication interrupted observation. Reopening the result after signing in proves preservation, not initial display latency.

We compared results for existing comparable subjects and separately checked changed values against late-arriving samples. Agreement between before-and-after outputs differs from independently recalculating every source record. The next optimization is to separate CPU time, network waits, and transformation costs within source collection.

Show states that let users choose their next action

Users need to know what their work is doing, more than which internal tool was called. The UI shows job phases for preparation, collection, calculation, and reporting, alongside completed units, total units, and lookup failures. Finishing collection differs from completing the report. Do not invent a remaining-time estimate if it has not been measured.

When a completed server analysis left a stalled progress card, we fixed the connection between polling and authentication renewal. 401 and 403 led to an authentication-state check; 404 meant the conversation was absent. A new token restarted polling without discarding completed answers. We also checked the active conversation so late responses could not appear in a newly selected one.

Desktop and mobile synthetic authentication tests verified polling recovery, answer preservation, and prevention of duplicate completed-result requests. These differ from deliberately reproducing expiry for a production user. The goal is not to hide failures. Users should be able to choose the relevant action: confirm authentication, reopen, or retry.

Distinguish a follow-up asking about analysis conditions from a request for a new calculation. A saved manifest is enough to explain which period a previous analysis used. Unnecessary recalculation adds latency and cost and may produce different values from a source that has since changed.

Add an approval and resume contract for research documents

Applying these principles to research plans and performance-evaluation reports broadens the meaning of completion. Generated prose alone does not establish readiness for submission. Source evidence, calculations, rule checks, review comments, and human decisions must be checked together. The following workflow comes from a proposal and implementation specification; it is not presented as an operational outcome.

Separate authoring, validation, and provisional review of submission readiness. Provisional approval is a different state from a person's formal approval. Using several models does not, by itself, establish independent verification. Reviewed calculation tools check values, units, and denominators; the generating model connects their results and evidence to the document.

Retrieval returns accessible document versions and source locations. Selecting a citation should open the actual passage. A revised source creates a new document version and review rather than overwriting an approved document. Preserve that evidence contract when extending relationship retrieval and RAG. Our RAG quality regression evaluation guide explains how to evaluate retrieval separately.

An approval request pins the document version and hash, evidence bundle, policy, and authorized approver. An independent reviewer checks review-confirmation questions, reference answers, and evidence before use. Passing those questions does not automatically approve the document or fully prove comprehension. A person makes an explicit decision after current authorization and request-bound reauthentication checks. Rejection does not require correct answers; it checks authority and the stated reason.

Persist long waits outside Runtime memory. Strands interrupts, resumption, and session persistence provide execution mechanisms, while the application owns the organization's approval ledger.⁹ Step Functions callback waits provide another resumption mechanism.¹⁰ A resumed tool checks the committed decision, current document, and authorization. Mandatory approval tools must not use a policy that silently trusts subsequent calls after one approval.

The design also specifies how evidence storage and decision commitment relate. An S3 preparation package is not a final approval. The business database commits the decision and its outbound event together, then stores and verifies immutable evidence referencing that decision. Until verification succeeds, show committed with evidence_state=pending, and withhold the approval-complete display and resumption. Storage retries continue the same decision rather than creating another approval.

Direct document editing and skill improvement are separate outcomes. Human edits to generated prose improve that document. Skill improvements are measured by pinning the same inputs, evidence, and release configuration, then regenerating with the revised skill. Assess whether correction effort falls while approval responsibility and reproducible evidence remain intact.

Pin and evaluate a release larger than the model

A model ID alone cannot explain an execution. Changing prompts, tools, skills, rules, templates, or retrieval configuration changes results even with the same model. Our code connected model and inference options, prompt components and hashes, and code versions to execution traces. The research-document design extends this principle into a release bundle.

This JSON is a design example illustrating the proposal's version-pinning principle. The identifiers are fictional. It is neither an AWS API request schema nor an execution result.

{
  "status": "design-example",
  "release_bundle": "release-example",
  "versions": {
    "model": "model-version",
    "prompt": "prompt-version",
    "skill": "skill-version",
    "rules": "rules-version",
    "template": "template-version",
    "retrieval": "retrieval-version"
  },
  "evaluation": "evaluation-for-this-bundle",
  "activation": "owner-review-required"
}

In-flight executions retain their starting bundle. Evaluate a candidate against the baseline with identical inputs, and apply only an approved bundle to new executions. Recovery returns to a verified previous combination, rather than changing only a prompt. Check that the deployed code, Runtime, worker, and UI versions actually match.

Evaluation includes compound requests, empty data, lookup failures, unauthorized requests, cancellation, authentication renewal, and duplicate delivery alongside normal questions. Document workflows add conflicting evidence, denominator mismatches, revisions, revoked permissions, delayed receipts, and resumption of stale approval requests. A model-generated average score cannot decide numerical correctness or approval.

Compare models and inference options by role under the same evaluation. Intent extraction and long-document authoring need not share the same reasoning budget. Choose a smaller model or lower effort where the observations support it, while preventing a classification failure from changing authorization or calculation boundaries. See model and prompt selection evaluation for a concrete comparison process.

Choose the next improvement from actual symptoms

Start with a real task that fails often or makes users wait. Divide its time into acceptance, inference, tools, persistence, and display, then specify the results and evidence required for completion. Before skipping computation or reducing checks, identify what the system repeats.

Capture before-and-after results and regression cases for representative tasks first. Then extend verification to repeated measurements, concurrent load, cost per request, and recovery time. Connect this work to AI PoC production-readiness gates for broader ownership and release criteria.

Operating a good agent on AgentCore requires fast responses and verifiable completion together. Stop when the required result is ready, preserve long work so it can be reopened, and connect review-sensitive decisions to evidence and accountable people. Clear boundaries make the effects of changing models, caches, and tools easier to measure accurately.

To assess request latency, job recovery, and evaluation and release criteria together, see Cloud & infrastructure and Data & ML engineering for the implementation scope.

References

Product behavior and official documentation were checked on October 14, 2026. The article distinguishes implementation observations from proposed designs.