AgentsNexus India 2026 conference notes

A full day of keynotes and expert sessions on agentic systems, platforms, security, and production AI. Agenda: https://agentsnexus.io/agenda

One-line summary of the day: the industry has stopped arguing about whether models are smart enough and moved entirely to the surrounding problems — context, memory, identity and authorisation, evaluation, and who the agent is actually building for. Four separate speakers independently landed on the same claim: the model is not the bottleneck.

---

Agenda — Main Conference

Sessions marked (no notes) below were attended without notes or missed.

---

1. Manish Gupta — AI Models and Agents: A Marriage Made in Heaven?

Senior Director, Google DeepMind · Keynote

The lineage he traced

Deep learning → the Transformer (the Attention Is All You Need architecture) → BERT (2018) → PaLM 540B, the first of Google's true foundation models → ChatGPT as the consumer moment → Gemini 2.0 → 3.0 → SIMA 2.

The point of the lineage: agentic capability is not a separate research programme bolted onto models. It fell out of frontier models getting good enough at reasoning that you could hand them a goal instead of an instruction.

Open research problems he named

• Efficiency — cost per useful unit of work, not raw benchmark scores
• Staged reasoning — structuring the thinking process rather than one undifferentiated chain
• Safety
• Uncertainty calibration — the model knowing how confident it should be
• RL reward hacking — models optimising the measurable proxy instead of the goal
• RL for non-verifiable domains — reinforcement learning works when you can check the answer (maths, code). Most real work isn't like that, and this is the open frontier.

MatFormer — elastic "Matryoshka" models

MatFormer = Matryoshka Transformer, from Google DeepMind (NeurIPS 2024, arXiv 2310.07707). Instead of training a separate 2B, 7B and 70B model, you train one universal model with nested sub-structure: the first m₁ neurons of each feed-forward block form a valid small model, the first m₁+m₂ a larger one, and so on. Sub-models can be extracted without any additional training, and layers can be "mix'n'matched" across granularities to produce exponentially many models.

This is the architecture behind Gemma 3n's E2B/E4B pair — E2B is not a distilled sibling of E4B, it is literally inside E4B. (Verified against the MatFormer paper and Gemma 3n write-ups.)

One model, many sizes, chosen at deployment time to fit the latency and cost budget of the device in front of you. This is what makes the on-device story in section 10 economically possible.

SIMA 2 — where agents are heading

SIMA = Scalable Instructable Multiworld Agent. SIMA 1 (2024) learned 600+ language-following skills across commercial games, acting only through rendered pixels and a virtual keyboard/mouse. SIMA 2 (Dec 2025, arXiv 2512.04797) replaces the low-level policy with a Gemini reasoning core, so the agent forms internal plans, explains its intentions, and — the important bit — self-improves: Gemini generates the tasks and the reward signal, and later generations outperform earlier ones with no additional human demonstrations. Paired with Genie 3 it transfers into worlds that were generated, not authored.

His four implications

1. Greater ability to solve harder problems.
2. Economically unviable problems become viable to solve — Jevons Paradox. (Jevons: when a resource becomes more efficient to use, total consumption of it rises rather than falls. Applied here: as intelligence gets cheaper per token, we don't spend less on it — we find vastly more problems worth pointing it at.)
3. AI skilling becomes imperative for every person.
4. Opportunity to develop AI models and agentic solutions that bring benefit to billions.

Point 2 is the one worth internalising. The interesting opportunity is not "do the current work cheaper" — it is the enormous class of problems that were never worth solving at old prices and now are.

Indian language support in Gemini

Gemini Live's Indian-language coverage expanded from 13 to 25+ languages and dialects. Previously launched: Hindi, Bengali, Marathi, Telugu, Tamil, Gujarati, Urdu, Malayalam, Kannada, Punjabi, Nepali, Odia, Assamese. New in this release: Sanskrit, Maithili, Santali, Manipuri, Dogri, Konkani, Bodo, Haryanvi, Chhattisgarhi, Magadhi, Bhojpuri, Marwari, Mewari. Still unsupported among India's official languages: Sindhi, Kashmiri.

Robotics — Gemini agent goals

Physical-world agents (Gemini Robotics) get framed around five properties needed simultaneously: General (can do anything it's being asked), Agile (solves long-horizon whole-body tasks and can navigate the environment), Dexterous (solves long-horizon manipulation tasks reliably and efficiently), Teachable (can be taught new tasks intuitively and efficiently, including calibrating to new robots), Interactive agent (can naturally and responsively interact with people; personalized and connected to the world).

AquaScope — continual learning on incidents (case study)

A concrete production example of a self-improving agent: AquaScope, an SRE agent that learns continually from outage incidents. Flow: an outage incident plus O(10K) telemetry streams and the codebase feed AquaScope's abductive reasoning step; its output goes to an Alert Based Verifier; verified experience is distilled by Pensieve into an Experience Knowledge Base; an Experience Retriever pulls relevant past incidents back into the next reasoning pass, closing the loop. Same shape as SIMA 2's self-improvement (generate the task, generate the reward, learn without new human demonstrations) — applied to reliability engineering instead of games.

Self-improvement agentic system for model efficiency

A second self-improving loop, this one aimed at server configuration rather than incident response — labelled "Flow Autoresearch Loop" on the slide. Given a goal (e.g. "improve latency"), an Idea proposer suggests a change, a Coder implements it as code modifications, a Benchmarker measures it, a Verifier checks correctness; failures loop back as feedback to the idea proposer or trigger a retry, and both successes and slowdowns get written to a shared Knowledge Base of skills and tools that the next iteration draws on.

AquaScope and this loop are both instances of the same claim in section 2 below: for a frozen model, all "learning" has to happen by writing better skills and knowledge back into memory, not by retraining weights.

---

2. Michael Hunger — Agents in Context

VP, Product Innovation, Neo4j · Keynote

The strongest talk of the day, and the one everything else in the afternoon kept pointing back at.

The framing: an agent is a brilliant new hire on day one

Day-one human: smart, trained, useless.

A fresh model instance has:

• No local context
• No memory
• No experience
• No empathy

What actually makes a new hire useful over the following months is not more intelligence. It's docs, code, a mentor, and shadowing — watching how decisions get made. Most of the value transferred there is tacit knowledge, and tacit knowledge lives in links: links between artefacts, and links between people.

His LangChain-flavoured line on this: "Communication is all you need." The failure mode is almost always context and instructions, not a model that isn't smart enough.

Humans store data and then reconstruct meaning from links. Agents don't have that reconstruction ability — so the links have to be given to them explicitly.

Definition of context

Giving exactly the information the agent needs to do the task — that is the context.

Not "everything we have." Not "the biggest window we can afford." Exactly what the task needs. Links come in two flavours: static (fixed references) and dynamic (resolved at runtime).

The agent loop

Think ──▶ Act ──▶ Observe ──▶ (Think …)
          │        │
    invoke tools   response from the action

ReAct = Reason + Act, with context threaded through. Hanging off the loop is judgement — supplied by a human or another agent — expressed as approvals, evals, and traces.

Context failure modes

The response is not "add more retrieval." It is to organise and alter the information so it is more understandable to the consumer. Retrieval is a formatting problem as much as a search problem.

GraphRAG = hybrid search (keyword + vector) plus dynamic graph traversal — you find an entry point by search, then walk the relationships from there rather than returning a flat list of chunks.

Memory — where learning actually lives

Since the model doesn't change, all learning has to live in memory and context. Graphs for memory:

• Short-term / episodic — what happened
• Long-term / semantic — what is true
• Agent traces — the record of how it acted

Skills as distilled memory

A skill is distilled memory — transferable experience.

The pipeline: successful execution → optimize → generalize → transfer. That is learning, and it's the only kind available to a frozen model.

But he was blunt about the current limitation:

Skills can't execute. Can't iterate. Can't self-modify.

A SKILL.md file is a static artefact. It doesn't run, doesn't learn from its own outcome, and doesn't rewrite itself. His proposal: skill as a graph — steps as typed nodes, data flow as typed edges. Then:

• Use scripts where the work is deterministic
• Use prose where judgement is needed

…and compile human-written skills into graph form automatically. The progression he sketched: resemblance → recurrence → transfer, operating across task context, memory, skills, teams, and the organisation.

Reference: agentskills.io — the Agent Skills open standard. Originated at Anthropic as the Claude Code skills mechanism and released as an open specification on 18 Dec 2025; now lives in the agentskills/agentskills repo and is adopted by OpenAI Codex, Cursor, GitHub Copilot, Gemini CLI, VS Code and others. A skill is a folder with a SKILL.md (YAML frontmatter + instructions), optional scripts/, references/, assets/. Loading is three-stage progressive disclosure — name+description at startup (~30–50 tokens), full SKILL.md on trigger, referenced files only during execution. (Verified against the spec repo.)

The gap Michael is pointing at is real and it is a product-shaped gap: skills as they exist today are documentation, not programs. Nobody has shipped the compile-and-improve loop yet.

Graphs bring better context to agents

His summary visual for the whole talk: a graph contributes knowledge, context, memory; an agent contributes language, reasoning, planning. Neither half is sufficient alone — "better together."

Book recommendations

Two just-published references he pointed to: GraphRAG: The Definitive Guide (O'Reilly, early release — Stephen Chin, Michael Hunger & Jesus Barrasa) and DuckDB in Action (Manning — Mark Needham, Michael Hunger & Michael Simons).

---

3. Anurag Krishna — Nobody should be hand-writing Automation

Principal Product Manager, UiPath · From Coding Agents to Agentic Orchestration

Notes captured: building automations using coding agents.

From the session abstract: prompt to production — how coding agents build automation in minutes, and what it takes to run that automation against real enterprise systems without it falling over. The thesis is that the artefact a human produces shifts from the automation itself to the specification of the automation, and the hard part moves downstream into orchestration, permissions and failure handling. (Thin notes — abstract-supplemented.)

---

4. Pratul Kumar Chakravarty — From Automation to Autonomy

Head of Data and AI Consulting, Adobe

The single line worth keeping:

Governance and trust: without it, agentic deployment fails.

Automation executes a path someone already decided. Autonomy means the agent selects the path. The moment that transfer happens, the enterprise question stops being "does it work?" and becomes "who is accountable when it works differently than expected?" — which is a governance question, not a model question. This is the same theme Karthik and Shuva Jyoti attacked from the identity and credentials side later in the day.

The proof is already in production

Three case studies he opened with, each paired with a distinct lesson:

Sources cited on-slide: Klarna CX data (Bloomberg, 2025); IQVIA/NVIDIA (2026); J.P. Morgan research (2026).

Balancing autonomy with governance

Not every decision deserves the same autonomy — calibrate it to confidence and business impact & reversibility:

The 5% pattern — what separates the agents that scale from the ones that stall, applied consistently: bounded scope from day one · full audit trail on every action · human escalation, built in. "This is exactly the matrix on the left — applied consistently."

The roadmap to operationalize at scale

Four stages: Foundation (0–2 months) — data readiness, governance policy, target architecture → Pilot (2–4 months) — one bounded agent, full observability, human review → Scale (4–9 months) — multi-agent orchestration across a second domain → Institutionalize (9+ months) — governance embedded in enterprise risk & audit.

Five things to leave with

1. Agentic AI isn't hype — it's systems that plan, decide, and act, and it's already live at Klarna, IQVIA, and JPMorgan.
2. Architecture — memory, tools, governance — determines whether an agent scales or stalls.
3. Autonomy is a spectrum. Calibrate it to business impact and reversibility, not maximum automation.
4. Governance built in from day one is what separates the 5% that scale from the 95% that stall.
5. The roadmap from pilot to production is well-defined — the advantage now goes to whoever moves first.

---

5. Panel — AI Agents are ready. Is your enterprise ready? (no notes)

Moderator: Michael Hunger (Neo4j) · Panelists: Venkappa Mala (Qualcomm), Karthikeyan Ranasthala (LottieFiles), Madhav Sikka (DevRev)

Premise from the agenda: the technology has moved fast — agents can plan, reason and act across systems today — but enterprise adoption is a different problem altogether. No notes taken.

---

6. Karthik Rameshkumar — The YOLO Agent Is Coming

Field CTO, Entire · Running agentic AI in production without losing control

Who/what Entire is

Entire is an AI-native developer platform founded by Thomas Dohmke, former CEO of GitHub. Emerged from stealth Feb 2026 with a $60M seed (led by Felicis; Madrona, Basis Set, M12 participating) at a reported $300M valuation. The product is a fast, distributed, Git-compatible network for mirroring repositories so agents can clone at speed without hitting origin rate limits — plus a Git-compatible store that unifies code, intent and reasoning. Their open-source CLI, Checkpoints, passed 4,600 GitHub stars in five months. Karthik joined from GitHub, where he was Field CTO for APAC. (Verified via Entire's site and press coverage.)

His framing line elsewhere, which matches the talk: infrastructure has to be built with agents at the centre of the experience, because agents are now equal citizens on the software team.

From the notes: composable primitives, open source. Install via entire.io → install.sh, then entire enable.

The ideal shape of an agent credential

*The task should be authenticated and authorized at every invocation.* Not at session start. Every invocation.

Every credential must answer: who, what and when, why.

Three planes

• Data plane — what the agent can read and write
• Control plane — what it's allowed to decide
• Execution plane — what it's allowed to actually run

Separating these is what makes the "YOLO agent" survivable: an agent can be fully autonomous inside a narrow execution plane precisely because the control plane is checked independently on each call.

---

7. Jay Thakkar & Shubha Saxena — From Clicks to Agents: Building Actions with Google ADK (title only)

Impulsive Web · Logitech

Notes captured: title only.

From the abstract: how everyday mouse actions become triggers for AI agents using Google ADK (Agent Development Kit) — clicks and gestures as the input surface for agent invocation rather than a chat box. Given Shubha's role (Personal Workspace Solutions at Logitech), the angle is peripherals-as-agent-triggers. (Not captured — abstract only.)

---

8. Shuva Jyoti Kar — Securing MCP with Intent-Bound Ephemeral Identity

Principal Engineer, Palo Alto Networks

The building blocks

Harnesses, firewalls, agents — the three things in the security picture. The harness is what wraps the model, the firewall is what sits on the tool path, the agent is the thing you cannot trust.

The rules

• Authentication comes before authorization — and both should be small. Narrow identity, narrow permission. Neither should be a broad grant.
• Add expiry to the key — immediately after the work is done, not at some scheduled interval. The credential should be dead before anyone could reuse it.
• The agent should not be able to do damage even with a successful prompt injection. This is the actual test. Not "can we prevent injection" — you can't, reliably — but "what is the blast radius when it lands?"

The gap nobody has closed

*Authorization of tools and payloads is not done. The injection happens on the tool path*.

Most MCP deployments authorise the connection and then trust every call that flows through it. The payload of an individual tool call — the actual arguments ��� is unauthorised. That's the hole. "Intent-bound ephemeral identity" is the proposed fix: a credential that is minted for one declared intent, valid for one invocation, and dies on completion — so a hijacked tool call carries an identity that cannot authorise the thing the attacker wants.

Pairs exactly with Karthik's four-property credential table above. Two speakers, different companies, same conclusion: the unit of authorisation must shrink from session to invocation.

The mechanism, slide by slide

MCP already verifies the key; now bind it to the job. MCP authorization today: the MCP server acts as an OAuth resource server, the client requests a token for the intended resource, the server validates the token's audience, and the flow runs on PKCE, HTTPS, and no token passthrough. Intent-bound authorization adds four steps on top of that: attest the client and agent runtime, canonicalize the authorized task, mint a short-lived proof-of-possession credential, and re-evaluate claims on every tool call. OAuth verifies the key. Intent binding verifies the job.

Every credential must answer four questions — framed on-slide as "task-bound authority," with a plumber called to fix an apartment as the worked example:

Every tool call rechecks both the key and the job — five checks run on every single invocation: Trust (certificate chain and trust domain) → Audience (token targets this MCP server) → Possession (presented key matches the cnf claim) → Intent (action, resource, and constraints still match) → Freshness (expiry, nonce, max-use, revocation state). A valid key attached to the wrong job is denied, explained, and recorded.

Worked example — a hijacked instruction cannot widen the credential. Requested task: isolate on prod/checkout-api pod-7d9, gated on condition malware_score > 0.90. Injected actions from a compromised prompt: export_secret on payments-prod, disable_alerts on all services. Both are DENIED — action mismatch, resource mismatch, missing precondition. As the slide puts it: containment — not prompt-injection prevention.

---

9. Vasundhara Shukla — Your Agent Has a Memory Problem: Why Knowledge Graphs Matter

Developer Advocate, Neo4j

The goal: persistent, explainable AI agents

Not just agents that remember, but agents that can be asked why. That requirement is what forces a graph rather than a vector store.

Three layers of memory

The third layer is the one vector databases cannot give you, and the one every enterprise buyer asks about first.

Why a graph — three reasons

1. Resolve identity — the same person appears as tejas@, T. Kalpande, and @tejask0. A graph collapses them into one node. Embeddings won't.
2. Traverse context — relationships between nodes are first-class and walkable, so you can follow a chain rather than hoping the right chunk ranks in the top-k.
3. Preserve provenance — evidence for every claim, which is what makes explanation possible.

Relations are not metadata. They are the memory itself.

The best line of the conference. A vector store treats the relationship as an incidental property of a record; a graph treats it as the record.

Multi-agent implication

The context graph is shared between collaborating agents. Memory stops being per-agent scratch space and becomes shared substrate — which is also how you get consistency across a fleet without passing giant blobs of text around.

---

10. Kartikey Rawat — Accelerating On-Device Agentic AI with Qualcomm QMX

Senior Engineer, Qualcomm

Terminology note: the session title says QMX = Qualcomm Matrix Extensions, a CPU instruction-set extension for accelerating matrix maths (and hence LLM inference) on mobile CPUs — Qualcomm published a Llama-on-CPU acceleration write-up on it in April 2026. My notes recorded AIMET, which is a different Qualcomm artefact covered in the same talk. Both are real; they sit at different layers.

The two phases of LLM inference

This is the single most useful mental model from the talk, and it explains almost every on-device optimisation decision. Prefill has a big batch of tokens to multiply at once, so the silicon is saturated and you are limited by raw FLOPs. Decode processes one token at a time against the full weight matrix, so you are dragging the entire model across the memory bus for every single token — arithmetic intensity collapses and you are limited by bandwidth, not compute. Which is why quantisation helps decode far more than it helps prefill: it shrinks what has to move.

Quantization

• A method to reduce the size of the model
• Improves latency (mostly by relieving the memory-bound decode phase, per the above)

AIMET

AIMET = AI Model Efficiency Toolkit, from the Qualcomm Innovation Center — an open-source library for quantizing and compressing trained PyTorch and ONNX models: post-training quantization (Cross-Layer Equalization, AdaRound), quantization-aware training, and compression via Spatial SVD, channel pruning and Weight SVD. It analyses per-layer sensitivity so you can see which nodes tolerate low precision. Repo: github.com/qualcomm/aimet (older mirror: quic/aimet). Data-Free Quantization gets many popular networks to INT8 with <1% accuracy loss and no training data. (Verified against the Qualcomm repo and announcement.)

Notes captured: "analyse the nodes" — which is exactly the per-layer compression-sensitivity feedback AIMET provides.

Ties back to MatFormer in talk 1: elastic architectures choose which model fits the device; quantisation and QMX decide how fast that model runs once it's there.

---

11. Jayita Bhattacharyya — Making Agents Reliable & Self-Evolving

AI Engineer, domyn

Anatomy of a traditional prompt

Role · Task · Context · Reasoning · Output format · Stop conditions. That's the hand-written approach — and her point is that hand-writing it is the problem, not the solution.

DSPy is better

DSPy — declarative self-improving Python. You write signatures (what goes in, what comes out) rather than prompt strings, and the framework compiles those into actual prompts and optimises them against a metric.

Prompts → programs. You stop tuning English and start compiling a program.

Built-in modules referenced: Chain-of-Thought (CoT) and ReAct.

Evaluation — three tiers

1. Labelled data — compulsory. No labels, no evaluation, no reliability claim.
2. Rule-based checks — deterministic assertions on structure and content.
3. LLM-as-judge — ⚠️ warning: bias. Judges favour verbose answers, their own model family's style, and the first option presented.

GEPA — optimize anything

GEPA = Genetic-Pareto, a reflective prompt optimizer (arXiv 2507.19457, "Reflective Prompt Evolution Can Outperform Reinforcement Learning", Lakshya A. Agrawal et al.; presented at ICLR 2026; available as dspy.GEPA).

How it works, and why my note says "Reflection LM & Task LM": the task LM (student) runs the program on training examples and is scored by a metric; the traces and scores go to a reflection LM, which reads them in natural language, diagnoses what went wrong, and proposes new instructions. Candidates are kept on a Pareto frontier rather than collapsing to a single best. Reported results: outperforms GRPO (a reinforcement-learning method) by ~6% on average and up to 20%, using up to 35× fewer rollouts, and beats MIPROv2 by >10%. When optimising a small model it's worth using a larger model as the reflection LM. (Verified against the arXiv paper and DSPy docs.)

The insight underneath GEPA: when the thing you're optimising is written in natural language, the optimisation signal should also be natural language. A scalar reward throws away almost all the information a failed run contains.

Observability

Named as a first-class requirement rather than an afterthought. You cannot improve what you cannot trace — which is the same argument Vasundhara made from the provenance side.

---

12. Panel — The New Developer Stack: Building, Debugging, and Trusting AI Agents (no notes)

Moderator: Karthik Rameshkumar (Entire) · Panelists: Ankur Dhir (Adobe), Animesh Dutta (Arm), Harshit Rohatgi (UiPath)

Premise: building with agents doesn't look like traditional software development — the toolchain is different and the debugging is different. No notes taken.

---

13. Erik Thorelli — Make What Agents Want

Head of Developer Experience, CodeRabbit

The most commercially interesting talk of the day, and the one with a thesis rather than a technique.

The pillars

• Agents are the new target users / customers.
• Highly autonomous agents are here now
• Huge potential outside dev tools — this is not a developer-tooling niche
• AI intelligence ≠ human intelligence. Designing for one does not automatically serve the other.
• Coding agents are the leading edge, not the whole market

What is intent?

Why the agent exists, and what it's trying to do.

Everything in AX design reduces to serving that intent.

What is good design?

Research, iteration, thinking.

Great design is a moat.

Book recommended: The Design of Everyday Things — Don Norman.

Agent Experience (AX)

Good for both humans and agents: semantic HTML · a clear CLI · well-named variables · good docs.

Good for humans, actively bad for agents:

Walls of text can be better. The instinct to chunk, paginate and prettify is a human-UX instinct and it destroys agent-readability.

Why AX?

• High intent, almost zero switching cost. An agent arrives to do something, not to scroll — and if your surface is hard to use, it leaves for the next one instantly. There is no brand loyalty, no habit, no sunk cost.
• The only thing that matters is whether it can accomplish the intent well.

How to AX

• Prompt for AI agents — terse, token-efficient
• "Bash is all you need" — sandboxed bash as the universal interface
• CLI over GUI
• Context lakes — bulk, queryable context rather than curated pages
• Reliable truths, trust and safety

⚠️ On negative instructions in AGENT.md: phrasing like "DO NOT DO XX — IT WILL BE HORRIBLE" can degrade the effectiveness of the agent. Negative constraints consume attention and prime the very behaviour they forbid. Write what to do, not what to avoid.

What to keep in mind

• Measure both quantitatively and qualitatively
• Agents are an entirely new user class — not a segment of your existing users
• Claude and Codex are your VIPs. Build for these; test against these first.
• Useful (for now) — the parenthetical was his, and it's honest: this playbook has a shelf life

Reconstructed fragment (LOW confidence): my notes have the line "change stack, security, Slack" under this section with no surrounding sentence. Best reading given the context: adopting agents as a user class forces changes to your stack, your security model, and your team communication (Slack) — i.e. the second-order organisational costs of taking AX seriously. Not verifiable from the notes; treat as my reconstruction, not his words.

---

14. Varsha Saha — From Playground to Production: Voice Agents (no notes)

Principal Engineering Manager, Microsoft — building voice agents via foundry; quick path to production.

15. Manikantha S — Building Agentic Products for the Next Billion (no notes)

Head of Product, Sarvam — demo-to-production gap: real volume, reliability, and making money.

---

16. Ashish Tiwari — 1 Million Tokens Are Not an Agent's Memory

Principal Solutions Architect, Search & GenAI, Elastic

Search: BM25 or vector?

BM25 (Best Match 25) is the classical lexical ranking function — it scores documents by term frequency and inverse document frequency with length normalisation. It matches words. Vector search matches meaning.

Exact vs semantic — and semantic is approximate, always.

That's the trade in one line. Vector retrieval at scale uses approximate nearest-neighbour search: you accept a probability of missing the true best match in exchange for speed. If the user typed an error code, a SKU or a name, BM25's exact match is not a legacy fallback — it is the correct tool. Hence hybrid.

Four kinds of memory

The title's argument: a million-token context window is working memory only. It's rebuilt from scratch every session, it degrades as it fills (see Michael's context-rot table), and it costs money proportional to its size on every single call. Episodic, semantic and procedural memory all require a store outside the window. Growing the window doesn't produce memory any more than a bigger desk produces a filing system.

Five things to steal, whatever you are building on

His closing practical slide, credited to Elastic Agent Builder: context management:

1. Load instructions lazily. Stubs first, full text only when needed.
2. Keep large results out of the conversation. Park them, pull on demand.
3. Return the passages that matter, not whole documents.
4. Compact for what the next turn needs. Oldest is not the same as least useful.
5. Connect at the source, with the user's permissions. Do not let agents hoard copies.

Two paths, and five numbers worth watching

His build-it-Monday slide, split into write-time and read-time discipline:

Five to watch: recall@10, MRR, tokens per turn, compaction events, and partial hits.

Third speaker of the day converging on the same point — Michael Hunger from the graph side, Vasundhara Shukla from the explainability side, Ashish Tiwari from the retrieval side. Memory architecture is the consensus 2026 problem.

---

Cross-Cutting Themes

1. The model is not the bottleneck. Said explicitly by Michael Hunger ("mostly the issue is context and instructions, not that the model isn't smart"), and implied by Erik, Ashish and Jayita. Everyone has moved on to the surrounding system.
2. Memory is the consensus hard problem — and three independent speakers said context windows are not memory.
3. Authorisation must shrink from session to invocation. Karthik and Shuva Jyoti arrived at the same architecture from opposite directions.
4. Relations/links are the substance, not the metadata. Vasundhara said it about graphs; Michael said it about tacit knowledge; they're the same claim.
5. Agents are a user class, not a feature. Erik's talk is the only one that treated this as a market thesis rather than an engineering detail.
6. Optimisation is moving from prose to programs — DSPy signatures, GEPA reflection, skills-as-graphs. Nobody serious is hand-tuning prompts by the end of 2026.

---

Resources Mentioned

---

Key Takeaways

1. "Giving exactly the info the agent needs to do the task is the context." Not more retrieval — better-organised retrieval.
2. "Relations are not metadata but the memory itself." The single best line of the day.
3. A million-token window is working memory only. Episodic, semantic and procedural memory must live outside it.
4. Authorise every invocation, not every session. Scope narrow, lifetime ~15 min, single use, checked each time.
5. The real security test is blast radius after a successful prompt injection, not injection prevention.
6. Skills today can't execute, iterate, or self-modify — that gap is unfilled and product-shaped.
7. Agents are a new user class with high intent and zero switching cost. Optimise for accomplishing the intent, not for looking good.
8. Prefill is compute-bound (GEMM); decode is memory-bound (GEMV). This explains most on-device optimisation choices.
9. Negative instructions in AGENT.md can degrade agent performance. Write what to do.
10. Jevons Paradox is the business frame: cheaper intelligence means far more problems become worth solving, not the same problems done cheaper.

---

So What — For Me

Two things here are directly usable, and one is a distraction I should name as such.

Usable — Agent Experience as a product thesis. Erik's "agents are the new customers, with high intent and zero switching cost" is the only claim from the day that describes a market rather than a technique. Zero switching cost cuts both ways: it means whoever makes their surface the easiest for an agent to accomplish an intent on wins by default, with no incumbent advantage to overcome. That's a rare structural condition and it won't last. Worth a hard think about which boring surface I could make agent-first before its incumbent notices.

Usable — the skills-as-graphs gap. Michael Hunger stated plainly that skills can't execute, iterate or self-modify, and proposed the compile-to-graph fix without anyone having shipped it. I already maintain a live skill library and a self-hosted vault-plus-agent setup, which means I have the one thing most people evaluating this idea don't: real usage data on which skills fail and why. That's a genuine unfair advantage. It is also deep infrastructure with a developer-tooling buyer, which historically monetises badly for a solo founder — so treat it as a thesis to interrogate, not a project to start.

Distraction — the on-device / quantization material. It's the most intellectually satisfying section in these notes because it's closest to my RISC-V and systems background, and that is precisely why it's a trap. QMX, AIMET, GEMM/GEMV are excellent for credibility in a conversation and worth nothing toward shipping a SaaS product. Filed as reference, not as a direction.

The honest gap in the day: every talk was about how to build agents well. Nobody talked about how to find someone who will pay for one. That's still my actual bottleneck, and a conference full of engineers is not where it gets solved.

---

The three themes, written up on their own

Three ideas came up in more than one talk, so I pulled each into its own note the next day rather than leaving them scattered across the sessions above. Those three notes follow, unchanged. They repeat some of what is above on purpose: the sections above are what each speaker said, and these are what I think the day actually amounted to.

Agent Memory — Layers and Knowledge Graphs

The core claim: a context window is not memory. It is working memory only — rebuilt from scratch each session, degrading as it fills, and billed on every call in proportion to its size. Everything durable has to live outside it.

---

1. Why the model can't be where learning lives

The weights don't move between sessions. So all accumulated learning must be stored in memory and re-injected as context. This is the whole reason memory architecture matters — it is the only place an agent can improve without retraining.

---

2. The four memory types

Growing the context window only grows the first row. A bigger desk is not a filing system.

Provenance is arguably a fifth layer — why it acted. Vector stores can't give you this, and it's the first thing an enterprise buyer asks for.

---

3. Why a graph rather than a vector store

Three jobs embeddings do badly:

1. Resolve identity. tejas@, T. Kalpande and @tejask0 are one person. A graph collapses them into one node with aliases. Similarity search gives you three loosely-related vectors.
2. Traverse context. Relationships between nodes are first-class and walkable — you follow a chain of reasoning rather than praying the right chunk lands in top-k.
3. Preserve provenance. Every claim keeps an edge back to its evidence, which is what makes an explanation possible rather than plausible.

Relations are not metadata. They are the memory itself.
— Vasundhara Shukla, Neo4j

A record store treats a relationship as an incidental property of a row. A graph treats the relationship as the record. That distinction is the whole argument.

Multi-agent consequence: the context graph becomes shared substrate between collaborating agents, rather than each agent hoarding its own scratch text and passing blobs around.

---

4. Retrieval: exact, semantic, or both

BM25 (Best Match 25) is classical lexical ranking — term frequency × inverse document frequency, with document-length normalisation. It matches words. Vector search matches meaning.

Exact vs semantic — and semantic is approximate, always.

Approximate nearest-neighbour search trades a probability of missing the true best match for speed. So if the query contains an error code, a SKU, an ID or a proper noun, BM25 isn't a legacy fallback — it's the correct tool. Hybrid search exists because neither mode subsumes the other.

GraphRAG = hybrid search (lexical + vector) plus dynamic graph traversal. Search finds an entry point; the graph walk finds the rest. This is strictly more powerful than returning a flat ranked list of chunks, because the second hop is where the actual reasoning chain lives.

---

5. Practical implications

• Decide, per fact, which of the four memory types it belongs to. Facts filed in the wrong layer are the usual cause of "the agent forgot."
• Don't solve a memory problem by buying a bigger window. Solve it by moving the fact out of the window.
• Store the edge, not just the two nodes. If you're recording "Tejas → attended → AgentsNexus", the edge type and its timestamp are the retrievable part.
• If you can't answer why the agent did that, you have no provenance layer and no explainability story — regardless of how good the retrieval is.

---

Context Engineering for Agents

Definition: giving exactly the information the agent needs to do the task — no more — is the context. Not everything you have. Not everything that fits.

---

1. The day-one-hire model

A fresh agent instance is a brilliant new hire on day one: smart, trained, useless. It has no local context, no memory, no experience, no empathy.

What makes a human hire useful over the following months isn't more intelligence — it's docs, code, a mentor, and shadowing: watching how decisions actually get made. Most of that transferred value is tacit knowledge, and tacit knowledge lives in links — between artefacts, and between people.

Humans store data and reconstruct meaning from links. Agents have no reconstruction ability. The links must be handed over explicitly.

Corollary: when an agent fails, the first hypothesis should be missing or badly-organised context, not insufficient model capability. That's the correct prior in 2026.

---

2. The agent loop

Think ──▶ Act ──▶ Observe ──▶ (Think …)
          │        │
    invoke tools   response from the action

ReAct = Reason + Act, with context threaded through each pass. Hanging off the loop is judgement — human or agent — expressed as approvals, evals, and traces.

Links feeding the loop come in two kinds: static (fixed references) and dynamic (resolved at runtime).

---

3. The five context failure modes

The fix is not more retrieval. It's organising and reshaping the information so it is more understandable to the consumer. Retrieval is a formatting problem as much as a search problem.

---

4. Stop writing prompts; compile them

A hand-written prompt has a fixed anatomy: role · task · context · reasoning · output format · stop conditions. Writing that by hand and tuning the English is the thing to move away from.

DSPy — declarative self-improving Python. You declare signatures (inputs → outputs) and the framework compiles and optimises the actual prompt against a metric. Prompts become programs. Built-in modules include Chain-of-Thought and ReAct.

GEPA — reflective prompt evolution

GEPA (Genetic-Pareto), arXiv 2507.19457, available as dspy.GEPA:

• A task LM runs the program; a metric scores it
• Traces and scores go to a reflection LM, which reads them in natural language, diagnoses failures, and proposes new instructions
• Candidates are kept on a Pareto frontier rather than collapsed to one winner
• Reported: beats GRPO (an RL method) by ~6% average / up to 20%, with up to 35× fewer rollouts; beats MIPROv2 by >10%
• When optimising a small model, use a larger model as the reflection LM

The underlying insight: when the artefact being optimised is written in natural language, the optimisation signal should be too. A scalar reward discards nearly everything a failed run knows about why it failed.

---

5. Evaluation — three tiers

1. Labelled data — compulsory. No labels, no evaluation, no reliability claim. This is not negotiable and it is the step everyone skips.
2. Rule-based checks — deterministic assertions on structure and content. Cheap, fast, catches most regressions.
3. LLM-as-judge — ⚠️ bias warning. Judges reward verbosity, favour their own model family's style, and over-pick whichever option was presented first. Useful, never authoritative.

Observability is a first-class requirement, not an afterthought. You cannot improve what you cannot trace.

---

6. Skills — and what they can't do today

A skill is distilled memory — transferable experience.

The pipeline: successful execution → optimize → generalize → transfer. For a frozen model, that is the only available form of learning.

The current limitation, stated bluntly at AgentsNexus:

Skills can't execute. Can't iterate. Can't self-modify.

A SKILL.md is a static document. It doesn't run, doesn't observe its own outcome, and doesn't rewrite itself. The proposed direction — skill as a graph: steps as typed nodes, data flow as typed edges, with human-written skills compiled into that form automatically.

Design rule that falls out of it:

• Scripts where the work is deterministic
• Prose where judgement is required

Progression across an organisation: resemblance → recurrence → transfer, spanning task context, memory, skills, teams, org.

Standard: agentskills.io — Agent Skills, originated at Anthropic, released as an open spec on 18 Dec 2025, now in the agentskills/agentskills repo and adopted by Codex, Cursor, Copilot, Gemini CLI, VS Code and others. Folder with SKILL.md (frontmatter + instructions), optional scripts/, references/, assets/. Three-stage progressive disclosure: name+description at startup (~30–50 tokens) → full SKILL.md on trigger → referenced files only during execution.

---

Agent Experience (AX)

The thesis: agents are the new target users and customers — an entirely new user class, not a segment of your existing one. Design for them explicitly, because designing for humans does not automatically serve them and often actively harms them.

---

1. Why this is a market thesis, not a technique

High intent, almost zero switching cost.

An agent arrives to do something, not to browse. Two consequences:

• High intent means every visit is a conversion opportunity — no funnel, no nurture, no awareness stage.
• Zero switching cost means no brand loyalty, no habit, no sunk cost. If your surface is hard to work with, the agent leaves for the next one in the same second.

That combination is structurally unusual: it strips incumbents of their main defence. Distribution, brand and habit — the three things that normally protect a market leader — mean nothing to an agent. Whoever lets the agent accomplish its intent most reliably wins by default.

This condition is temporary. It is worth acting on while it lasts.

What is intent? Why the agent exists and what it is trying to do. Every AX decision reduces to serving that.

---

2. What's good for both — and what only looks good

*Good for humans and agents:*

• Semantic HTML
• A clear CLI
• Well-named variables
• Good docs

Good for humans, actively bad for agents:

Walls of text can be better. The instinct to chunk, paginate and prettify is a human-UX reflex and it destroys agent-readability.

---

3. How to do AX

• Write prompts and docs for agents: terse, token-efficient. Every token you waste is money and attention you took from the task.
• "Bash is all you need" — sandboxed bash as the universal interface.
• CLI over GUI.
• Context lakes — bulk, queryable context rather than curated pages.
• Reliable truths, trust and safety.

⚠️ Negative instructions degrade performance

Phrasing like "DO NOT DO XX — IT WILL BE HORRIBLE" in an AGENT.md can reduce the effectiveness of the agent. Negative constraints consume attention and prime the very behaviour they forbid. Write what to do, not what to avoid.

---

4. What to keep in mind

• Measure quantitatively and qualitatively — agent traffic needs its own analytics, not a bot filter
• Agents are an entirely new user class
• Claude and Codex are your VIPs. Build for these; test against these first.
• Useful (for now) — this playbook has a shelf life and its author said so

---

5. Design

Great design is a moat.

Good design = research, iteration, thinking. Not taste applied at the end.

Book: The Design of Everyday Things — Don Norman. Recommended specifically because affordances, signifiers and discoverability are exactly the vocabulary AX lacks. The questions are identical; only the perceiver changed.

---

6. AX and security are the same design problem

An agent-first surface is also an agent-attackable surface. The two rules from the security talks at the same conference apply directly:

• Authenticate and authorize at every invocation, not per session. Ideal credential: scoped to one task, ~15-minute lifetime, single use, checked every time. Every credential answers who / what and when / why.
• The real test is blast radius after a successful prompt injection, not injection prevention. Assume the injection lands.
• Separate the data, control and execution planes. An agent can be fully autonomous inside a narrow execution plane precisely because the control plane is checked independently.
• The unclosed gap industry-wide: *tool payloads are not authorised.* Most deployments authorise the connection and then trust every call through it. The injection happens on the tool path.

---

7. Open question for me

If agents are a user class with zero switching cost, the winning move is to make some boring existing surface agent-first before its incumbent notices. Which surface? — that's the unanswered half, and it's a market question, not an engineering one.