Field notes · · 7 min read

What the AWS Summit Tel Aviv agenda says about agents

The September 2026 agenda paired building and running agents with optimization, observability, and evaluation.

Editorial illustrationCreated for this story. GrantTap screens below are separate captures made with sample data.

AWS Summit Tel Aviv took place at Expo Tel Aviv on September 10, 2026. Its published agenda is a useful signal of the questions teams are asking now: how to build agentic applications, operate them reliably, observe their behavior, and evaluate the outcome. This article reads the public program; it is not a report of first-hand attendance.

The event page described agentic AI alongside serverless and cloud innovation. The Building AI & Agentic Apps track included sessions on production-grade Bedrock applications, an introduction to running agentic applications, best practices, and scaling AI through optimization, observability, and evaluation.

From the agenda to operational questionsBuild, operate, and observe summarize the agenda; govern comes from separate AgentCore documentation. This is editorial analysis, not a session report.
01BuildProduction-grade and introductory agentic applications
02OperateBest practices for running agentic systems
03ObserveOptimization, observability, and evaluation
04GovernWho may invoke tools and how outcomes are traced

From demo to operating system

A short demo can show a model calling a tool. Production work asks who may call it, with which credentials, under which conditions, and what happens when the response is late or missing. The program's pairing of building sessions with observability and evaluation suggests this operational turn. That is an inference from the agenda, not a claim about what any speaker said on stage.

Separate AgentCore documentation gives one governance example: requests routed through its gateway can be evaluated by policy, with decisions logged. The Summit agenda itself does not establish that local shell commands or every provider-native route pass through such a gateway.

Editorial illustrationAI-generated conference-inspired scene. It is not a photograph of AWS Summit Tel Aviv or a depiction of its actual stage.

Why this matters to GrantTap

GrantTap works at a different scale from AWS infrastructure. It follows local coding Tasks across computers and supported providers. Yet the operational questions are familiar: is this capability allowed, did the correct host apply the decision, did the action run, and can a person inspect the result without reading every transcript?

The answer should be a chain of evidence, not a single success badge. A Mesh policy, a host receipt, an actual invocation, and a verified outcome are related but separate. This is why governance and usage have become central product work rather than decoration around a chat window.

The theme to carry forward

Our reading of the published program is a shift from agent demos toward operating questions. Building, observability, and evaluation appear in the same track; governance is a related question drawn from AgentCore documentation, not a named session in that track. For a local coding product, the practical version is to keep the person informed where judgment is needed.

Conference agendas are evidence of emphasis, not proof of market share or a universal industry priority. We will keep testing these ideas against actual tasks, host behavior, and user decisions.

Read the program for what it says

The official agenda is a record of scheduled sessions and their descriptions, not evidence that a particular attendee adopted a practice or that a speaker delivered a specific conclusion. Its Building AI & Agentic Apps track is nevertheless revealing as an editorial source. Building production-grade applications appears alongside running agentic systems, best practices, and scaling through optimization, observability, and evaluation. The juxtaposition invites a practical question: what changes once an agentic demo must operate repeatedly under real conditions?

The event overview also presents agentic AI among broader cloud and serverless topics. It would be inaccurate to say the entire Summit was solely about governance or that governance was a named session in this track. The first generated image is deliberately conference-inspired, not documentary photography. We rely on the linked AWS pages for dates, session titles, and descriptions; the visual conveys the theme without pretending to record the room.

Building is only the first stage

A prototype can show a model receiving a request and calling a tool. Repeated operation introduces other questions: what input was accepted, which tool identity was selected, how a timeout is handled, and how a person can inspect a result. These are general engineering questions, not quotes from a Summit talk. Their relevance follows from placing development, running, optimization, observation, and evaluation in one program track.

An evaluation should name the task it measures and the outcome it considers successful. A trace can explain an execution path, but tracing alone does not say whether the answer was useful. Optimization can reduce cost or latency while harming completeness. These concepts need to remain separate. The agenda suggests that teams are discussing them together; it cannot prove that any one architecture solves them for every application.

Editorial illustrationGenerated editorial operating loop based on topics in the published agenda; the policy gate refers to separate AgentCore documentation.

Governance comes from another source

AWS AgentCore Policy documentation provides a distinct example of governance: policy evaluation for requests routed through an AgentCore gateway, with decisions recorded. This is separate from the Summit agenda. Its scope matters. A gateway can enforce the calls that pass through it, but the documentation does not make a local shell command or every provider-native coding route flow through that gateway. We should not transfer a cloud service guarantee to a different execution path by analogy.

The broader lesson is still useful. A human or organization chooses a rule, an execution boundary applies it, and evidence shows what happened. If an action takes another path, the claim of enforcement must narrow accordingly. In a local coding product, that boundary is often the connected computer and its provider integration. The second generated illustration puts a policy gate beside the operating loop to show a related question, not a session that appeared on the conference stage.

Why observability alone is insufficient

A dashboard can show that an agent ran. It may not show whether its action was authorized, whether the right computer executed it, or whether the resulting code passed tests. Observability helps locate events and failures; evaluation judges a defined outcome; governance constrains certain actions. All three are valuable, but none should silently stand in for the others. A request accepted by a gateway is not a verified business result, just as a prompt delivered to a coding provider is not a completed Task.

A practical evidence chain might name the request, selected rule, enforcement decision, actual invocation, and independent result. If the result is unknown, keep it unknown. If a model answer is reviewed but the deployment has not run, report that distinction. These distinctions are especially important on a phone, where compact presentation can tempt teams to collapse several states into one attractive success badge.

The local coding analogy

GrantTap follows Tasks across supported local coding executions. The comparison to AWS infrastructure is about questions, not identical products. Which host is responsible? What capability is requested? Which policy was applied? Did a tool run? What did tests or a reviewer verify? Those questions make sense whether an application is hosted in a cloud service or a coding agent works on a developer's laptop, although the actual enforcement mechanisms differ.

GrantTap's current coverage also has limits: provider routes differ, Cursor has a narrower control path, complete cross-host capability bundle transfer is unfinished, and unknown usage remains unknown. The conference program offers a useful frame for building, running, observing, and evaluating agents; it is not an endorsement of GrantTap. The practical test is whether a local product can answer those questions with evidence from its actual host path.

A disciplined takeaway

Use the Summit program as a reading list and prompt for design review. For a system you operate, pick one agent workflow and identify its builder, runtime, observation path, evaluation criterion, and policy boundary. Then try a failure: an unavailable tool, a delayed response, or an action denied at the boundary. Can a person tell what happened and what remains unresolved? That exercise is more informative than repeating a broad claim that ‘agents are the future.’

The official sources below support the event date, published track, and AgentCore policy example. Our conclusion about an operational turn is an inference from those sources, not a report of attending the conference. The actual GrantTap screen below uses deterministic sample usage and does not show AWS data. The article's central theme is therefore deliberately modest: as agentic applications grow, trustworthy operation requires a traceable path from decision through execution to a checked result.

GrantTap Usage on iPhone with deterministic sample values. These are not AWS Summit metrics or live customer telemetry.
GrantTap screen · sample dataGrantTap Usage on iPhone with deterministic sample values. These are not AWS Summit metrics or live customer telemetry.

Sources

Next storyAgent governance must reach the computer →