Nacho Martinez (Oracle) presents a workshop on building agent harnesses around a fixed model, applied to an autonomous anti-money laundering (AML) agent that flags suspicious bank transactions. Topics include the agent stack, agent loop, short- and long-term memory (episodic, procedural, semantic), context engineering, toolbox and skillbox patterns, skill distillation, instruction hierarchy, and continual learning for frozen models, plus a UI walkthrough and Q&A. The talk argues the harness around the model is where practitioners can make the biggest gains. # Channel Presentation Observations — "Memory-Aware Agent Harnesses for Anti-Money Laundering" (Nacho Martinez, Oracle) ## Observable Audience Addressed - **Software engineers and AI practitioners**, not end consumers. Evidence: "most of the engineers that I talk to… we use these systems every day"; discussion of vector stores, context windows, MCP, ACID consistency assumes technical fluency. - **Financial-industry professionals specifically** at this event: "they told me that there's going to be a lot of people from… Wall Street uh I adapted this workshop to be around a bank." - **Consultants named as an ideal audience**: "if you're a consultant you are my perfect uh use case or my perfect user for this workshop because you could be creating a custom harness… for a financial agent." - **Developers with GitHub accounts**: onboarding via "sign up with your GitHub handle" and GitHub Codespaces. ## Claimed Scope of the Content - **Educational/workshop format, hands-on**: "the workshop instructions in a QR code or in a website"; "the notebook student"; a guided AML fraud-detection agent demo with "fake data." - **Claims to teach the agent harness as "the most interesting topic in AI"**: "the harness is actually one of the most interesting topics in AI I think is the most interesting topic in AI nowadays because these harnesses actually control everything that the AI agent can do." - **Broad technical curriculum**: agent stack, agent loop, memory layers (episodic/procedural/semantic), context summarization and compaction, skill/tool vectorization, instruction hierarchy, files-vs-databases tradeoffs, hybrid retrieval (RRF). - **A pragmatic, anti-maximalist stance** the creator explicitly promotes: "my solution is that for some cases some of these solutions work with files, for some other cases they work with databases… We don't have to go into only one of them." ## Self-Description Evidence (Explicit Creator Statements) - **Professional identity**: "My name is Nacho Martinez. I am an AI developer advocate and a data scientist by heart." - **Affiliation**: works at Oracle — "because I'm a database guy because I work in Oracle"; "come to the Oracle booth." - **External content presence**: "just find me on YouTube. I have podcasts, I have workshops, I have everything." - **Course credential**: "we recently released a course with Andrew Ang and deep learning AI about building adaptive AI agents… a free course." - **Ongoing projects**: "we are experimenting with this… actually Richmond and I because we actually want to create a way in which you can plug into external internal or third party skill hubs." - **Personal investment in audience**: "I will pay for it myself. So you can use this workshop and play with it as you wish." ## Demonstrated Presentation Patterns - **Interactive, Q&A-driven**: multiple audience questions answered live (files vs. databases/work trees, MCP benefits, memory-layer design), plus in-person logistics ("my colleague Richmond… everyone's table"). - **Accessibility-minded**: repeatedly shares the workshop URL and QR code for "the people who are on YouTube," acknowledging a remote viewing audience distinct from the room. - **Opinionated but hedged**: creator marks recommendations as proposals — "which we propose," "my idea is," "I would say" — rather than absolute claims. - **References third-party tools by name**: Claude Code, Codex, "spy" (Pi), "open claw, hermes agent," Grok model on OCI, OpenAI, Anthropic. ## Claims vs. Demonstration Distinction - **Claims**: harness customization is more tractable than frontier-model work; smaller context windows perform better ("the smaller the context window is the better it will solve a problem"); tools/skills consume "~80% of the whole request." - **Demonstrated**: a live notebook-based AML agent application (Grok model on Oracle Cloud) with database inspection, context-window visualization, and suspicious-activity report generation — supporting, but not independently verifying, the claims. # Delivery Observations — Nacho Martinez, "Memory-Aware Agent Harnesses for Anti-Money Laundering" ## Overall register The delivery is **conversational, workshop-host style**: informal openings, frequent audience check-ins, and self-deprecating humor. It reads as a talk designed to hand off quickly to hands-on work rather than a polished keynote. - Opens with logistics and a joke about attention span: > "if you don't want to listen to me, you think I'm boring or something, you can start uh on your own on the workshop as I'm speaking" - Jokes about spending: > "I paid too much money for that domain. So, uh, use it." and later "and of course, I'm paying for it, so don't worry about that." ## Recurring phrases and verbal habits - **"Right?" as a rhetorical tag** — extremely frequent, used to seek agreement mid-explanation: > "That's suspicious, right? because why would you like put $1 million in and then just like distribute uh like that." - **"Like I said" / "as I said"** — recurring signposting: > "Like I said, we don't have a lot of time. So I'm going to try to be quick." - **"We don't get (a lot of) control over..."** — a repeated framing device contrasting the model vs. the harness: > "the reasoning part of it uh is provided by the frontier labs and we don't get a lot of control over that"; "we don't get any say in what the decisions are." - **Human-analogy habit** — he systematically maps agent components onto human faculties: > "kind of like us humans we have our brain it's augmented by a database for memory also like our brain"; "the context like our attention is also limited like our agents we can't watch seven movies at the same time." - **Self-corrections in real time** — he audibly fixes imprecise statements rather than editing them out: > "Well, not exponentially, quadratically, let's say just quadratically"; "uh I will not go d uh I will not deep dive into them." - **"Uh" and "you know" fillers** are dense throughout, consistent with unscripted, live delivery. ## Teaching habits - **Question-to-audience-then-answer pattern.** He poses a problem, pauses for crowd input, then confirms: > "can anyone tell me what is the workaround that agents use to solve uh this specific problem... Any ideas?" → audience: "Work trees." → "Exactly. Good." - **Show-of-hands polling** used twice: > "raise of hands who doesn't use AI agents like cloud code etc" and later "a show of hands for who likes pi okay less than I expected." - **Concrete toy examples before abstractions.** The suspicious-transaction scenario ($1M deposit, $50K ATM withdrawals) precedes the theory of the agent stack. - **Deliberate scoping / deferral.** He repeatedly names a topic and explicitly postpones it to the workshop: > "we'll focus on each of them but I will not go... deep dive into them because we'll actually do that in the workshop." - **Named-number precision** when citing mechanics, which anchors the informal style: > "a maximum of 60 seconds of reasoning for each one of the iterations"; "each skill is like 3,000 5,000 uh tokens"; "80% of the whole request is uh is is tools and skills." - **"Does that answer your question?"** — a closing check after each Q&A response, appearing at least twice. ## Tone and stance signals - **Pragmatic middle-ground framing.** He positions himself against extremes (files vs. databases maximalists, model-first thinking): > "files are good for some things and databases are good for for other things. We don't have to go into only one of them." - **Mild self-effacement about time management:** > "So I thought like 15 minutes or 20 minutes went by, but one hour went by." - **Playful pressure inversion** when stepping back for the workshop portion: > "I'm gonna go through and do a round and if anyone has any questions we can chat in a less uh aggressive way because I feel observed and you probably feel no pressure." ## Stable patterns vs. isolated moments **Stable (repeated across the talk):** - "Right?" agreement-seeking tags - Human-body analogies for agent architecture - Control-vs-no-control framing (model vs. harness/data layer) - Deferring depth to the workshop notebook - Audience interaction checkpoints (hands, questions, "Does that answer your question?") **Isolated (thin evidence, do not generalize):** - The quip about domain costs and about "ruining people's lives" in the AML scenario — humor appears in bursts, not as a sustained comic thread. - The "I'm a database guy because I work in Oracle" identity claim appears once. - The "feeling observed" remark is a single moment of self-disclosure. ## Uncertainty notes - Some quoted tech names appear as transcript artifacts ("cloud code", "spy", "grog model", "open AAI", "Andrew Ang") — the exact intended referents (e.g., Claude Code, Pi, Grok, Andrew Ng) are probable but the transcript spelling is what is observable. - Repetition counts are approximate; fillers and tags occur far more often than the cited instances, but exact frequencies cannot be verified from the transcript alone. # Observation Record — Memory-Aware Agent Harnesses for Anti-Money Laundering **Video:** "Memory-Aware Agent Harnesses for Anti-Money Laundering — Nacho Martinez, Oracle" **Speaker:** Nacho Martinez (self-identified: AI developer advocate, data scientist at Oracle); audience members contribute brief spoken questions/responses (anonymous in transcript). Richmond identified as an on-site assistant and co-experimenter. --- ## 1. Session Framing and Logistics - Martinez describes the format: ~10–15 minutes of talk followed by a hands-on workshop accessed via **workshopwaitingroom.com** (GitHub-handle sign-up, GitHub Codespaces). - He frames the workshop scenario around a **medium-sized bank** with suspicious transactions in five categories, motivated by an audience of financial-industry attendees ("they told me that there's going to be... a lot of people that work in Wall Street"). - He also mentions a **free one-hour course with Andrew Ng and DeepLearning.AI** on building adaptive AI agents, positioned as covering the same subcomponents discussed in the session. ## 2. The Agent Stack Martinez divides the stack into: - **Application layer** — the interface users interact with. - **Model layer** — the "reasoning core," where "we don't get any say in what the decisions are." - **Data layer** — the focus of the talk, described as the part "everything that we can manipulate and work around is on." - **Infrastructure and compute** — supporting layers with less user control, especially with third-party models. Data-layer components he lists: the **agent loop**, **gateway/MCP** connections to external data, **memory layer**, **context engineering** (summarization/compaction), and **tools and skills**. ## 3. Application Shapes - Four categories: **LLM chatbots**, **RAG applications** (characterized dismissively as "a glorified vector search"), **LLM-driven workflows**, and **AI agents**. - Best systems (he names Claude Code, Codex, "spy" [Pi], "open claw, hermes agent") combine **automation (workflows)** with **autonomy (agents)** — what he calls **agentic systems**. - His position: consuming AI via chatbots or RAG alone is suboptimal; "a combination of automation and autonomy" is "the better way." ## 4. Definition of an AI Agent He defines an agent via human analogies: - **LLM reasoning** — "like us humans we have our brain." - **Memory via database** — augmenting the brain. - **Tools for actions** — "the equivalent of... our extremities." - **Inputs as senses**; **context/attention as limited** — "we can't watch seven movies at the same time." Control allocation: reasoning is provided by "frontier labs" with no user control; **memory, tool use, and perception** are controllable — these constitute the **harness**. ## 5. The Agent Harness — Central Thesis > "The harness is actually one of the most interesting topics in AI. I think is the most interesting topic in AI nowadays, because these harnesses actually control everything that the AI agent can do." - **Claim:** the same frontier model "performs better or worse for specific tasks" depending only on harness configuration; he asserts this "has been proven." - Harness components listed: model choice, storage, encoding/retrieval, memory structure, **semantic layer** (assumed-but-unstated context, illustrated with the audience "not singing" example), agent loop, and context engineering (optionally continual learning, bringing it to "seven... or eight different components"). ## 6. Files vs. Databases Debate - He characterizes the ongoing dispute: "files for everything" maximalists vs. "database maximalists." - His position — **both, by use case**: - Files are "great at storing lots of unstructured data." - Concurrent multi-agent file writes create consistency problems, currently solved by **work trees** (confirmed by an audience member). - His critique: "the work tree solution or the workaround has been already solved by databases 30 years ago... we're trying to reinvent the wheel." Transactional/ACID writes would remove the problem. - Qualification preserved: "Files are good for some things and databases are good for other things. We don't have to go into only one of them." ## 7. Memory Architecture - **Short-term memory:** the context window itself — "most things... just vanish" after a conversation. - **Long-term memory** categories (his proposal): - **Episodic** — tool logs, prior conversations, summaries. - **Procedural** — skills, workflows, skill sequences. - **Semantic** — user identity, preferences. - **Why not everything in short-term:** the context window is limited, and — his strong empirical claim — "the bigger the attention matrix... the worse it performs. And this happens for every model." He cites studies showing accuracy degrades with 256k tokens of context vs. near-zero, attributing current 1M limits to KV cache, and warns "the performance goes horribly" before advertised limits. - Mitigations: **context summarization** and **compaction** (chunking conversation into storage with IDs, retrieved by offset). ## 8. Agent Loop - Described as "the driver or the car" — context assembly (pulling skills, tools, files, database content), reasoning, API call, repeat. - Workshop loop has a **maximum of 8 iterations** and **60 seconds of reasoning per iteration** ("maximum patience"), explicitly to avoid credit exhaustion — presented as configurable, not a design principle. ## 9. Toolbox/Skillbox Pattern and Context Budget - **Problem:** he has ~100 installed skills at 3,000–5,000 tokens each; loading all would exhaust the window. - **Proposal:** vectorize tools/skills; the agent loop runs **vector similarity search** (k=3 in the workshop), loads only the most relevant, then offloads. He notes tools/skills can occupy **more than 50% of the context window**, and later states tool outputs and retrieved docs are "80% of the request... 35 to 100,000 tokens." - **Instruction hierarchy:** system prompt (highest weight) > developer/app instructions > user query > tools/skills (lowest weight, described as "plug-and-play"). - **Semantic cache claim:** tools/skills are attached to every chat-completions request, and "it would be four or five times more expensive if we didn't have this semantic cache" because providers avoid recomputing repeated content. (Presented as his understanding, not verified.) ## 10. Continual Learning - Question he poses and answers: how does a **frozen model** get better? Answer: work the **data layer**. - Three categories: **parametric** (weight modification), **representational** (embeddings), **non-parametric** (everything discussed in the talk — the workshop's focus). Defers parametric/representational detail to the DeepLearning.AI course. ## 11. Q&A Positions (preserved with qualifications) - **Episodic memory confusion across conversations:** "it depends on how much weight you give it" — vectorizing episodic memory may be preferable when pulling from prior conversations matters; in the workshop, "there is no confliction... because we have a clear separation on the memory components." - **Skills and system prompt:** skills carry "the least weight out of the four" in the hierarchy. He and Richmond are **experimenting** with precomputed-embedding skill/tool hubs for third-party MCP collections — presented as work-in-progress, not settled. - **Budget management:** context treated "as an n-dimensional matrix that starts at zero but it's never zero — it's closer to like 10,000." He cites a paper comparing harnesses, noting **Pi is "the most minimalistic and the most efficient"** (~6,000 tokens per request) vs. 30–40k for others. Workshop retrieves **three** tools/skills by default; a **reranker** could refine to one but "we are not using a reranker" in the workshop. Advice: "stick with it and stay consistent." - **Memory-layer advice:** "keep it simple... don't create too many abstractions." Start with two structures (short/long-term), promote valuable context to long-term as raw text, vectorize it, and add a "recall long-term memory" step between observing and reasoning, gated by vector-distance relevance thresholding. - **MCP relevance:** qualified — "MCP is not really that relevant in this case." Where useful: pre-created, proven SQL queries so agents avoid hallucinating engine-specific SQL across "15 engines" (Postgres, Oracle, "VSQL" [as transcribed]). - **Why embeddings over files for skills:** regex/keyword search over files degrades "quadratically" as files grow; embeddings capture "the hidden meaning that we as humans don't cannot comprehend"; recommends **hybrid search** (semantic + keyword, "RRF"), showing a workshop visualization where hybrid results fill a relevance gap between the two methods. Trade-off acknowledged: "a little bit more compute." ## 12. Closing Position — Custom Harnesses - He disclaims expectations: "I'm not expecting anyone... to just like start building their own custom harnesses because we already have great solutions in the market" (Claude Code, Codex, with a noted lukewarm audience show-of-hands for Pi). - Core recommendation: "Let's simplify the problems that you're trying to solve and then build custom harnesses that attach on to that." Consultants building domain-specific harnesses (e.g., financial) are "my perfect user." - Autonomous math agents (the OpenAI "10,000 agents" examples he references) require **automatic compaction/summarization and near-infinite patience by default** because they lack human-in-the-loop; the AML agent differs — it flags and reports rather than acting destructively ("it's not ruining people's lives by just... blocking the whole bank"). - On starting from scratch: "I would start from scratch because that way you get to strip 90% of what you don't need." He notes "everything is built around the chat completions API," with Anthropic and OpenAI standards as counter-efforts. - Demo notes: workshop agent uses a "grog model 4.3" [Grok/GPT as transcribed] on Oracle Cloud (OCI) with fake transaction data; the agent runs autonomously and produces **suspicious activity reports** for later human inspection. --- ## Unresolved Tensions Preserved - He champions building custom harnesses while simultaneously stating existing market harnesses suffice for most users — the recommendation is domain-scoped, not general. - The semantic-cache cost claim (4–5× expense without it) is asserted without citation. - The "same model, better/worse by harness" performance claim is attributed to prior proofs but not sourced in-session. - Files-vs-databases is explicitly left open: "this dilemma is still going on," with his resolution being a case-by-case hybrid rather than a verdict. - Skill-hub experiment with Richmond is explicitly tentative ("we are experimenting with this"). # Video Attribution & Provenance Record ## Video Metadata - **Title:** Memory-Aware Agent Harnesses for Anti-Money Laundering — Nacho Martinez, Oracle - **Format:** Conference session / workshop (approximately one hour), includes live coding demo and audience Q&A - **Video ID:** `01a15ca6-6bbc-7c5e-a8f0-1281376636af` ## Speakers & Roles ### Primary Speaker - **Nacho Martinez** — identified as **AI developer advocate** (self-described) at **Oracle** (per title metadata; Oracle affiliation is corroborated in-transcript: "I work in Oracle"). Also self-describes as "a data scientist by heart." - Role in video: session presenter, workshop instructor, and Q&A respondent. ### Secondary / Audience-Identified - **Richmond** — referred to by the speaker as "my colleague"; role in session: roaming assistant helping attendees at tables during the workshop. Also named as a collaborator on experimentation with plug-in skill/tool hubs. - **Audience members** — several unnamed questioners appear in Q&A (marked with `>>` in transcript). No names or specific roles are provided for them. ### Unnamed Third Parties Referenced (not speakers) - **Andrew Ng / DeepLearning.AI** — collaborators on a released course (speaker mentions "Andrew Ang," likely a transcription of Andrew Ng). - Named organizations/projects referenced: OpenAI, Anthropic, Oracle Cloud (OCI), Grok (referred to as "grog model"), Cloud Code, Codex, Pi ("spy"/"pi"), OpenClaw ("open claw"), Hermes agent, Postgres, VSQL. ## Referenced Sources & Claims ### Third-Party Claims & Studies - Speaker states there are "lots of studies" showing degraded model performance as context window size increases; no specific study is cited. - Speaker references "a paper comparing the efficiency of each harness" by first-request token count (Pi cited at ~6,000 tokens; other harnesses at 30–40k); no citation given. - Claims about **semantic caching** at OpenAI and other providers reducing costs for repeated tool/skill prefixes — asserted, not sourced. - Claims about **worktrees** as the current multi-agent file-write workaround; databases with ACID guarantees presented as the prior solution. ### Referenced Course (Promotional) - A **free one-hour course** co-released "with Andrew Ng and DeepLearning.AI" on **building adaptive AI agents** — self-promotional reference, flagged as promotion. ## Promotional Segments (flagged) - **DeepLearning.AI course** promotion (free course, explicitly recommended). - **Workshop and GitHub repo promotion** — workshop hosted via `workshopwaitingroom.com` (speaker notes he personally paid for the domain and pays for the Codespaces compute); ongoing invitation for attendees to use it after the event. - **GitHub repository** of workshops, sessions, and notebooks promoted at closing. - **Oracle booth** invitation ("come to the Oracle booth... until Wednesday evening") — promotional presence. - Speaker's own **YouTube content, podcasts, workshops** — self-promotion. - Note: speaker states the workshop's transaction data is "fake data" and the workshop compute is personally funded. ## Content Boundary Notes - The session combines a ~15–20 minute talk, a live application demo, and extended Q&A; the transcript conflates speaker statements with audience questions only via `>>` markers — questioners are not individually attributed. - Statements about the anti-money-laundering demo application describe a fictional "medium-sized bank" scenario, not a real customer or deployment. ## Availability - Workshop available via QR code or `workshopwaitingroom.com`; access via GitHub handle → repository invitation → GitHub Codespaces. Codespaces compute funded by the speaker. - The referenced DeepLearning.AI course is described as free and findable via search. - The recording itself appears addressed to a YouTube audience ("let me just reframe the question for the people who are on YouTube"), indicating the session is being recorded/streamed; no explicit availability limits are stated. ## Provenance Summary Table | Claim/Item | Source in Transcript | Attribution | |---|---|---| | Harness efficiency paper (Pi ~6k tokens) | "I was reading a paper" | Unnamed paper, speaker's claim | | Context-window performance degradation | "lots of studies have shown" | Unnamed studies, speaker's claim | | Semantic caching of tool/skill prefixes | Speaker assertion | No source cited | | Worktree workaround for concurrent file writes | Audience answer + speaker elaboration | Attributed to audience; elaboration by speaker | | Adaptive AI agents course | Speaker announcement | Speaker + Andrew Ng / DeepLearning.AI | | Workshop materials & repo | Speaker announcement | Nacho Martinez (and Richmond, per Q&A) | Hi. Hi everyone. Uh thank you for coming to this session. Uh we're it's going to be a session about agent harnesses. We don't have a lot of time. It's only one hour session. So um hopefully we have time to talk about a lot of things that that you guys are interested in and the the session essentially is going to be uh like me talking like 10 15 minutes about the topics that we're going to talk about and solve in the workshop. You have the workshop instructions in a QR code or in a website and if you don't want to listen to me, you think I'm boring or something, you can start uh on your own on the workshop as I'm speaking. But essentially this is this is what's uh happening on the website. You just um sign up with your GitHub handle and then you will automatically receive an invitation to the repository. The workshop is hosted on code spaces. So you can just like create a code space out of that uh and you will receive an invitation automatically to get access to the workshop itself and you just have to create a a code face over there uh opening GitHub code spaces and you're good to go and and and begin with the workshop. Uh so I'll just put the QR code uh one more time for those of you who were uh who who want to take that and I'll I'll get started. Okay, perfect. Uh, if you have any questions, also my colleague Richmond is over there. He's going to go through um, you know, everyone's uh, table. If you have any questions, just raise your hand and he can help out as well. Yeah, there you go. Also, the website, I mean, you can go to the website workshopwaiting room.com. I paid too much money for that domain. So, uh, use it. Okay. So, who am I? My name is Nacho Nacho Martinez. I am an AI developer advocate and a data scientist by heart. And if you're interested in anything about me, just find me on YouTube. I have podcasts, I have workshops, I have everything. Not going to go too much into myself. Um just one thing though uh we re recently released a course with Andrew Ang and deep learning AI about uh building adaptive AI agents which is one of the subcomponents that we're going to talk about today. And you know if you're particularly interested in the things that you can do on a model to make it better and adapt over time, learn over time, just check out that course. is a free course uh a 1hour course that you can check out on on Google. So what are we going to go uh through today? Like I said, we don't have a lot of time. So I'm going to try to be quick. Um but these are the things that we're going to talk about. First of all, what is the agent stack? Uh what are the components of an agent stack? What are the different shapes that an AI application can take? What an AI agent is? And what is the agent harness? what is the main motivation of building or working around agent harnesses rather than working with AI agents or with an LLM model directly and you know all the subcomponents of an agent harness like for instance memory context engineering memory engineering and all these things. So because they told me that there's going to be a lot of people from uh financial uh like a lot of people that work in Wall Street uh I adapted this workshop to be around a bank right so the idea is that the main premise of the workshop is this we are hearing lots of the uh nowadays like open AAI is launching 10,000 agents or 5,000 agents to solve this problem 10,000 agents to solve this mathematical problem that was solved like in a 100 years 200 years. The thing is that these agents are autonomous. They don't have any human in the loop until they arrive to uh to the conclusion or the answers, right? So the agents themselves don't have the capacity to do this. Why? Because I mean the context window is limited. The memory components are something that a large language model doesn't have inherently. So all these things we need to implement ourselves to make these agents able to solve all these problems for 10 hours 100 hours autonomously right. So the idea is that a lot of people are making focus on okay we have these frontier models but my idea is that okay we don't need to focus so much on the frontier models we can use them but let's work on the harness which is the interesting part and the things that you can actually customize uh more and more. So on this application, the idea is that it's a medium-sized bank that has lots of uh you know suspicious transactions uh sometimes and they are categorized into five different types. So for example, if you get like a million dollar transaction that's coming into your bank and automatically and magically uh for three days you're making like $50,000 withdrawals on an ATM. That's suspicious, right? because why would you like put $1 million in and then just like distribute uh like that. So the idea is that we have this medium by uh medium-sized bank that has lots of transactions and these transactions they need to be kind of autonomously decided or at least flagged so that a human that actually works in the bank needs to spend less time actually looking at these things you know. So let's go to the theory a little bit. What is the agent stack? Right? When we talk with an AI agent, we typically are talking with the application layer, right? Uh what we interact with either an an interface, a chatbot, an a mobile application etc. Then we have the model itself which is the reasoning core the the you know we don't get any say in what the decisions are. Uh and then we have also the infrastructure that supports it all and then the compute. But what we are going to focus about today is the data part of it. And the data is very important because everything that we can manipulate and work around is on this part. The other parts we get less control over them, right? Especially if we're using like a third party uh model that isn't ours. So the data layer is what we focus about uh today, right? First of all, we have the agent loop and this is arguably one of the most important parts of an AI agent. Uh the agent loop is in charge of essentially driving the whole thing. Uh and it's customizable as well. And inside the data, you also have like a gateway and MCP so that you can connect it to third party external data sources. You also have the memory layer which we will talk about later and essentially also some context engineering uh parts of it that let you automatically summarize and compact and shrink the working context window of a model and finally also some tools and skills uh which we can do some interesting and intelligent stuff so that we can essentially keep the context window limited. This is one of the main ideas of the workshop. Now, typically the applications that we interact with, they are either a combination of these four, right? LLM chatbots which are very easy. Lots of people just create an AI application, create a chatbot so that you can talk with it. You also have rag applications which is essentially like a glorified uh vector search. And then you also have LLM driven workflows and AI agents. And typically what most of us use uh by the way raise of hands who doesn't use AI agents like cloud code etc of course uh so cloud codec etc all these systems are a combination of three and four which is um you know a combination of LLM driven workflows that provide automation and AI agents that provide autonomy. So it's a combination of automation and autonomy and these are called agentic systems. The better systems like cloud code, codeex, spy, uh open claw, hermes agent etc. they are all a combination of these two types and most of the engineers that I talk to and this is important is that we use these systems every day, right? But we stop or a lot of people not a lot of people think about these problems when building their AI applications. So you might have an AI application but then you don't consume it like this. And this is something that we're going to focus on today because I think this is the better way of consuming um AI applications not only through chat bots, not only through rag applications but also through a combination of automation and autonomy. So what is an AI agent for those of you uh who don't know? It's a like a computational entity that is powered by an LLM by reasoning kind of like us humans we have our brain it's augmented by a database for memory also like our brain it's extended through tools for actions so the equivalent of a human would be like we have our extremities and we can interact with the world just like an AI agent can interact with an operating system through the tools that we give it they provide it and it's also grounded in inputs. So for for instance it would be like our senses for a human our eyes etc that let us perceive information and the context like our attention is also limited like our agents we can't watch seven movies at the same time like we will not understand any of the movies we will not focus on any of them so the context window for humans is similar to AI agents and kind of we try to assimilate or you know have some of these notions be closer to our human experience. experience and this is something that we'll we'll work on today. So the reasoning part of it uh is provided by the frontier labs and we don't get a lot of control over that and then we also have the things that we do have a little bit more control over which are the memory the tool uses and the perception right and this is the the harness itself. A harness is essentially all the scaffolding that you need to do to build uh these three components which is the the tool use the memory and the perception and we're not going to focus too much on the model because like I said we don't have a lot of possibilities on what to do right so the harness is actually one of the most interesting topics in AI I think is the most interesting topic in AI nowadays because these harnesses actually control everything that the AI agent can do. You give it a different configuration then the agent the same LLM frontier AI model that you're consuming becomes better or worse. Sometimes you know it's been proven that by just changing the harness the same model performs better or worse for specific tasks. So it's really really important to make focus on the harnesses and not a lot of people are doing this and like you said in a harness there are you know seven different or eight different components if you consider continue learning as well but there are lots of decisions that you need to make right you have the model you have the storage like where do you put the data uh you have some encoding and retrieval components like how do I make the distance between two vectors to actually retrieve the data properly uh what do I store in my memory? Do I think of it as short-term memory plus long-term memory kind of like humans have? Do I think of it in different uh compartments or different types of memory? uh also the semantic layer which is a part that's really um interesting because as humans we are here and we have some context that we have never said to each other right but we are sharing this for instance I'm a speaker and you are listening you are not singing right now why are you not singing because it's not appropriate in the semantics of the context that we are at right now right so the model itself also has access to the semantic layer which talks a little bit about all the things that haven't been set to the model but they are assumed. Also the agent loop which is like all the things that drive and automatically and autonomously make the agent work all over uh again and this uh is like one of the most important parts and also context engineering and we'll focus on each of them but I will not go d uh I will not deep dive into them because we'll actually do that in the workshop. So just for reference um there was this big discussion around files versus databases like lot of people were saying we need to use files for everything like you just put everything into a file and then like magically one month later the agent becomes better. Some other people are database maximalists and they want to put everything into a database. Right? So this dilemma is still going on and I would say that um well let let me give you an example like can can anyone tell me in this example that you see on the screen can anyone tell me what is the workaround that agents use to solve uh this specific problem that you're seeing on screen multiple agents writing to the same file. How does that work nowadays in AI agents? Any ideas? \>\> Work trees. Exactly. Good. So, work trees is the current solution, right? And this is a a thing or a workaround because files have an inherent problem in themselves, which is that they they like if multiple writes are coming into the same file, then you have problems with consistency like which right came first? If someone is reading, what do I do with this person that read the file before I modified it, etc. lots of problems, right? So for some things I will definitely tell you like files are great. Files are great at storing lots of unstructured data. Database on the other hand is also used for some other types of use cases. But my solution is that for some cases some of these uh solutions work with files, for some other cases they work with databases. So we actually um need to reconsider some of these things that are going on, right? Um, and the work tree uh solution or the workaround has been already solved by databases 30 years ago. And we're trying to reinvent the wheel with some of this. And we don't actually need to reinvent anything because there is an actual solution to this. For example, if you're trying to write to a file um at the same time multiple agents, if you had transactional consistency or acid consistency like atomic consistent isolated and durable um rights into the file, you would not get this issue. Right? So files are good for some things and databases are good for for other things. We don't have to go into only one of them, right? So in the agent harness just consider this as an as a thought. Uh another component is the all the memory components right and this comprises all the mechanics and the the systems that are created around an AI agent to make it use the information um and not only use this information but also be able to refine it and recall it appropriately when it's time right and agent memory you as the engineers you get to choose like what are the things in your agent memory layer that you're going to consider. Some people like the short-term versus long-term memory. And in this case, this is part two. We have some short-term memory components. For example, if we are talking with clot or with codeex, we have short-term memory in the sense that the context window itself is short-term memory. Anything that disappears after the conver like it disappears after the conversation, right? most things uh in the context window just vanish. Then you launch another conversation and it starts from zero. That's short-term memory. It's very limited. We cannot put everything into it. And then we also have long-term memory. And inside the long-term memory, we also have some categories that we propose. Uh, for example, episodic memory would be all the things that happened, all the episodes of our conversations, all the tool logs, the previous conversations, um, summaries of previous conversations that you've had with the agent, etc. They all go into this episodic long-term memory category. You also have procedures or procedural memory, which are all the things like skills, workflows, which are like a sequence of skills that are being run etc. All of those go into procedural memory. And also we have semantic memory which is all the unset like I said the agent remembers who you are what are your preferences what's your you know favorite framework etc all these things go into semantic memory so the problem the main issue here why cannot we put everything into the short-term memory because it's limited and it's not only limited but actually the bigger the attention matrix is and the attention matrix is essentially the the context window. The bigger it is, the worse it performs. And this happens for every model. There are lots of studies that have shown that if you start at zero tokens on the context window, the problem is being solved much more accurately than if you have 256,000 tokens already and the limit is a million right now. We're at a million because of the KV cache. All these things need to be considered and just know that even if the advertised limit stops at uh 256k or 1 million if you keep going the like the performance goes horribly. So the smaller the context window is the better it will solve a problem. And this applies for every type of problem that you can think of uh in humanity right and there are two types of things that tackle this. One is context summarization which you just ask it hey just generate a summary a short summary for me with this uh with all the things that have been said in the context window and then you get the summary and then you start off from the summary the next conversation that is fine. Uh, another one is compaction and that's kind of similar, but in compaction you're just like putting chunks of the conversation into the database or into a file and then you just put it with an ID and if the AI agent needs it later, it has the ID. It just pulls from the ID with an offset kind of like reading from a file, right? Some of the these are some of the problems that happen in context uh context engineering. And then we have the agent loop which is the driver or the the car that that drives all the components that we have talked about. We have a context assembly part that pulls from the skills pulls from the tools pulls from the previous conversation from the files from the database. All of these things just brings in uh brings into the context window dynamically. Then it does some reasoning. it makes an API call to open AAI or whichever model you're talking to and decides on what needs to be done and this happens you know automatically and infinitely if you want in my case in this agent loop that that uh we prepared for the workshop it has a maximum patience because I don't want to run out of openi credits or any any credits that I that I have but uh yeah the the maximum number of iterations in our case will be eight and a maximum of 60 seconds of reasoning for each one of the iterations, right? Um, but this is completely configurable. Like I said, as engineers, we have to say in what goes on into the agent loop, right? And also the toolbox pattern, the skillbox pattern, what we propose for this for storing tools and skills, which are hundreds. I don't know about you, but I have like a hundred skills already installed. I'm not putting a 100 skills at the same time into the context window because each skill is like 3,000 5,000 uh tokens. So that would automatically like go over the advertise limit in no time. I I would have no space for my actual conversation with the agent. So how do you fix that? Well, there are different ways, but what we propose is that you vectorize, you create vector embeddings out of the tools and out of the skills. And through those vector embeddings, once the agent loop, let me go back. Once the agent loop wants to retrieve some useful skills or tools, you're going to do vector similarity search against this vector store that you have. You're going to pull the most relevant skill or tool to solve it. You solve the problem and then you offload it again. And that's one of the ways in which you uh keep the context window relevant in this in this sense. And you know using skills and using tools is a very very uh common pattern like everyone's using tools like a bash command or a change directory all these are specific tools through bash right so we're using tools and skills constantly this is for some cases more than 50% of the context window that's being used right so I just want you to be mindful of the vast amount of context window size that is actually being kept by the skills and by the tools. Um we also have this idea called uh skill distillation where you take previous conversations, runs and you know actual like conversations that you've had with an AI agent and then you try to create something meaningful out of that. How do you do that? Well, you can do it in several ways, but one of the easiest ways that you can do it is just like create a skill MD and put it into the same skill box that you had everything before. And this is one of the ways like a Hermes agent, one of the innovators in this sense was creating skills that are particularly good to solve specific specific problems. Let's say that you're working on a front end. Well, if you're working on front end, you might want to create a skill that has worked very well for you with all your preferences. Hey, I like this coloring style, etc. And the next time you work on the front end, since you have created vector embeddings out of this, you can just like the agent will automatically choose the more relevant skill. So if you just mention, hey, I like this coloring style that I had in this other skill, it's automatically going to know that you're referring to the new skill because you use the word uh coloring style for for instance, right? So skill like skill distillation is one of the techniques that that you can use to improve the the learning the learning of a model over time. And it's the same uh this is uh related to what I what I was saying is that you have dynamic skill discovery in the sense that the agent loop when assembling or building the context will pull the right skills and the right tools when it needs and you know some people ask uh like how does a frozen model get better and what I mean by frozen is that we we don't get any control over the frontier models right uh but we do get control over all the data the data layer of it right and some people say hey let's modify the weights of the model some other people say let's create an embedding model that works better for this specific problem and then I'll worry about you know just retrieving the better embeddings there uh etc so there are different ways to do that but the idea is that this is the main component of continual learning and continual learning is one part of of of the things that you can do to make a mo model better. And there are three categories, right? You either work on the parametric memory. It's called parametric because it modifies the parameters of the weights of the neural network. You also have representational memory which is what it works with embeddings etc. And you also have nonparametric memory which is everything that we have spoken about today until this point. But um if you're interested in any of these three, we have focused on the third one. You also have the other two and I will not go into the uh into those two. There are lots of techniques like um you know creating low rank adaptation uh fine-tuning a model uh creating embeddings etc. And all these things you can find in that course that I I was referring to before which focuses on the three categories. So if you're interested just take out uh take that course if uh or chat chat with us after after the session. So after the session, we'll be in the event for the for the rest of the event too, right? And last thing I want to mention is that all of the things that happen during a chat completions API call to any uh OpenAI model or anything that you're using is that there is an inherent uh instruction hierarchy. What do I mean by instruction hierarchy? There is a different weight on the things that are given to the model. For instance, what we use to interact with is the user, right? The request. In this sense, this is the third most important thing that we can pass to a model. The most important one is the system prompt, right? Everyone knows about this the system prompt concept. Um, and the system prompt is fine, but it cannot hold everything because otherwise things would not have a hierarchy in itself. uh you need to actually put some of the things in the system prompt, some of the things in the user prompt and all the tools and the skills that the things that are made available, they have this hierarchy. And this is good because it it's it actually um lets us or lets the model focus more on some things than others and we'll also go through that in the workshop. So just for reference uh this is the the UI of the workshop. So if you're running it in code spaces already, you'll see that you have uh this deployed. I will go through through it uh with you. But this is essentially the way in which I envision someone that works in AML like um a fraud detection system in a in a bank interacts with an an autonomous agent. The autonomous agent is running in the background 24/7. It doesn't sleep. It doesn't need any of the humanly uh necessities that we have, right? It's connected through a harness to the to a database and it has all the functionalities that we have mentioned but on top of that uh it's autonomously making decisions for the company even when you know we're offline. It's not ruining people's lives by just like saying, "Hey, this this guy is suspicious. Let's just like block the whole bank and everything, you know, because I would ruin ruin the person's life, but rather it's making these decisions and just like printing them so that a human can actually inspect them later on, but it's going to save a lot of time during the, you know, the discovery process, etc. So by the end of the uh of the workshop, if you complete it, uh you're going to be able to have an agent that connects to a database that is actually working as if it was uh any any company and it's going to do autonomous analysis and decision making that then a human is going to take and interact with. So these are all the the components that we have talked about about the harness and without further ado I will uh put the QR code just again or workshopwaiting room.com um and if you want to check out any of the other workshops that we have uh you can just check out this GitHub repo we're making a lot of uh progress and effort into all the things that go in there everything from workshops sessions uh notebooks So you can get started on different topics like agent harnesses etc. So just check it out. Uh and let me let me go to my Firefox and show you how this application works. So, first of all, let me just uh for those of you who didn't receive an invitation, if you go to workshop waiting room.com, you will get an invitation via the GitHub API with your uh user to this repository. So, if you just go here and then open on GitHub code spaces, it's going to ask you uh to create a code space. And of course, I'm paying for it, so don't worry about that. uh just be careful with um with the hardware that you deploy because it's expensive. But uh the idea is that you will get a a deployment like this with a couple of notebooks and I'll show you the workshop itself and then my idea is for me to step down in a couple minutes and then we'll go through the you know people who have questions etc and then we'll solve it together. But it's automat automatically also deploys this application which essentially is tracking all the things and this is of course uh fake data. Don't worry I'm not exposing anyone here but it's essentially coming up with new transactions. Some of them are fine some of them are uh problematic. So the autonomous agent which is a grog model running on OCI it's essentially making autonomous decisions and some of them it's saying hey this one is suspicious let's add it to the list and then afterwards uh you also get like a way to visualize the context window of the agent here um you can also check out all the data that's already in the database uh here uh like all the customers etc and also an autonomous way in which the agent is actually going to make an analysis of all this um of of all this in real time, right? So, it's going to run through the tool calls that we give uh that we have available in our tool um in our toolbox. Uh yeah, it's sorry, it's a little small. Um you know, so it's going to go through the evidence. It's going to search for knowledge in the knowledge spaces that we created through vector stores. It's going to make a lot of tool calls. And finally, it's going to essentially go through the whole activity uh suspicious activity reports automatically. And here is just a fancy way of visualizing the 30 most recent um events that happen in the bank. But the workshop itself is this notebook, the notebook student. And what I want you to do is first of all just check out the different components that we have there because we are implementing them uh here. And I'm going to go through the first uh the first to-do. There are a couple of things that you need to do on the workshop just to confirm that that you know uh what you're doing. So first of all, let me just go ahead and show you uh the first part of the workshop, right? Uh you have this rock model 4.3 uh which is running on on cloud Oracle cloud and let's uh connect to the database of course. And after sorry, let me restart the kernel. Let me run this cell. Restart. But yeah, uh let let us know if you have any questions or issues uh when getting into the code space and then I'll step down and and do this with you and answer any questions. Any questions by the way so far? Okay. Yes. Uh the the repo. \>\> Yes, you can find it on workshopwingroom.com. And let me just put the QR code here. Uh this QR code if you want to uh scan it. And this will automatically give you access to to it via GitHub API. Okay. So let me re uh reframe the question for the people who are on YouTube. Um so he's asking about what happens with the episodic memory and all these memory components. Does it get it confused with previous conversations with a with an agent? Well, it depends on how much uh weight you give it. And this is why I was mentioning the instruction hierarchy as well. You might want to put this if it's a really really important thing and you actually wanted to pull from some place or the other place. Uh you can actually decide your memory layer architecture yourself, right? So you might want to for instance in some cases where the episodic memory is really important and you actually want to pull from previous conversations you might actually want to vectorize that rather than just save it as raw text right depends a lot on the on the use case. I would say in this case it doesn't uh it doesn't there is no confliction there because we have a clear separation on the memory uh components of the architecture. Yes. So the the skills can be added to to the system prompt. uh they typically um oh sorry they typically have a different uh yeah in the instruction hierarchy they have the least weight out of the four uh if you were to think about it it um it's typically here so it has the least weight I would think of it as a plugandplay place in which you can pull things and we are experimenting with this uh actually Richmond and I because we actually want to create a way in which you can plug into external internal or third party skill hubs and tool hubs for instance a collection of MCPS that you can give your agent availability by precomputing the embeddings of all of these things and once you have these precomputed embeddings you can just like say hey do vector searches against this third party uh group of skills or group of tools but rather than thinking of it as being included and by the way this is of course included in every open AAI or every chat completions API request that you're making to open AAI or any other model. This is attached at the bottom and this typically is like 80% of it like 80% of the whole request is uh is is tools and skills. But what what happens or like why don't you get charged like five times more than what you're charged now is because uh OpenAI and all these systems they have a semantic cache and they put uh if 80% of it was the same as the previous request it doesn't recomputee it just goes into the semantic cache and this allows you and this allows all of us to have um an a way in which to consume the Frontier Labs models in an economical way and of course it's still very expensive. But what I want you to understand is that it would be four or five times more expensive if we didn't have this semantic cache that just um puts the tools and these skills into it. Because in the response like remember that when you're interact with interacting with a frontier AI model, you're essentially making the whole thing through an HTTP request and everything like this would be for example 10K or 5K as a system prompt. you're an AI assistant and then you need to help me solve this this and that. You have the developer like the specific app instructions, the user query which is what we type in the chat which is negligible like 100 tokens thousand tokens maybe and then the tool outputs and the the retrieve docs which is 80% of the request like 35 to 100,000 tokens is already this in every request. Does that answer your question? \>\> One last. \>\> Yes. \>\> Okay. So his question was like how do you manage the budget and since there are so many things in the skillbox and the toolbox patterns like how do you essentially make this work right um we have a clear separation the context window we think of it as or think of it as an n-dimensional matrix that starts at zero but it's never zero it's closer to like 10,000 I was reading a paper that was comparing the efficiency of each harness on how much they put into the first system prompt and the first uh completions API request at the beginning. Pi, you know, Pi, the harness, that's the most minimalistic and the most efficient uh harness because it includes about 6,000 tokens at the beginning on every request. But if you go to other harnesses, they have more like 30 40,000 tokens. Um how do we we have a clear separation the context window? we just let the everything goes around the agent loop, right? So, let me go to the agent loop to show you uh one thing. The agent loop will control everything that it connects to, right? Um so here, for example, the agent loop. \[snorts\] Oh, I'm at the bottom. Hold on. Uh just as a reference um the agent loop. So here right uh the context assembly when you're working with it uh you will essentially build and you can go through this in the in the notebook. explain the notebook but um the context assembly is one part that first of all we have a maximum number of defined uh tools or skills to retrieve I think the defi the default number is three uh so every time a new request is coming it's determining and this is done by the model itself it's determining what is the thing to do then it's going to as try to assemble the context with the things that it needs to perform Right? And one of these things is retrieving the three most relevant tools, the three most relevant skills. And we are not using a reranker. But what you could also do is like at the at the end of uh the similarity search, you can also put an embedding model plus a reranker that will take those three and tell you out of these three, this is the most important one out of the three. And you could actually have a better refinement out of that because you you might not want to have a total of three skills loaded for every task. The task might be solvable by only one. Right? So the idea is that you can put uh whichever strategy you want just uh stick with it and uh stay consistent with it until the end. Uh so the idea in this case in the particular workshop is that we have a total number of uh vector searches that we're doing against one vector store which holds the tools another vector store that holds the skills k equals three and then out of the three you can retrieve the most relevant one with a reranker and then it's going to dispatch the tools of course and build a context window but this is entirely the decision and the job of the agent loop. Yep. Okay. So what is the most uh important or interesting way in which you you can interact with the memory layer of \>\> I mean the efficiency comes just from the number of entities that you create right so my first recommendation would be just like keep it simple uh so don't create too many abstractions or too many components of the memory layer so for instance try to experiment first of all with only short-term memory and long-term memory and just have two structures Right? If you think or if you have an agent that considers that something that was in the short-term memory or in the context window is kept is is worth keeping, you promote it to the long-term memory and you just put it somewhere as raw text. That's the easiest thing that you can do, right? Once you have it in text somewhere else in a long-term memory component or object, then you can take that vectorize it and then let it be explored by the agent loop in some way. So for instance, here you would just have like an extra thingy in the middle of observing and reasoning that lets the agent recall memories or something. You can call it like recall recall long-term memory. And this is going to make it uh be introspective before solving the problem once more. Uh, so it's going to go to your vector store or whatever you have this long-term memory uh, episode that you recorded in a previous conversation and from that you can let it see okay I'm going to let it pull from it if it considers it to be interesting or if the vector similar like if the distance between the vector of the query and what I have in my long-term memory is relevant enough and the distance is small enough then I will consider it into the context window if it's too big or it's not relevant enough then I will just discard it so it will be like a different an additional abstraction between the observing and the reasoning part there are ways we are not doing MCPS right here but one of the benefits of of using MCPS would be to solve um I would say that MCP is not really that that relevant in this case um but it depends on what you have in the database so for example If you have a database, you're interacting with a database like we are doing right here. Having an MCP is interesting, but one of the main problems that I like to say to people like what does an MCP solve, especially in the database, because I'm a database guy because I work in Oracle. Um, so one of the things that you can solve is letting AI agents make SQL queries, but by not hallucinating or trying to come up with a new SQL query every time. This is one of the bigger problems that that AI agents have with SQL. SQL has like 15 times like 15 engines like posgres, you have Oracle database, you have VSQL, you have like lots of different queries that work on SQL, but they have specific hints or subtleties in the query that makes it not not work well. Right? So the main problem that MCP solves in this case would be okay, I'm going to pre-create some SQL queries and then let the agents access those. So those queries are proven to work um rather than having an agent try to come up with a SQL query dynamically every time, right? Yep. Good question. Uh let me give you an example. So the most important thing would be the rapidness and that the meaning of the sentences and what the skill means itself. Uh rather than having it as text and if you were to store this just as text in a SQL file it would be able sorry in a in a file in the file system right in the operating system then you would have uh lots of ways in which an agent can do regular expression matching. So for instance, all the search would basically be either keyword search or like word search based uh into that skill which is fine. Um but the bigger that gets the less in like the the harder it gets for an agent. First of all, regular expression matching like GP is inefficient for huge files and sometimes if uh like the the file system grows and grows linearly, the performance of the regular expression matching decreases exponentially. Well, not exponentially, quadratically, let's say just quadratically. But this is one of the problems um that it doesn't scale as well as the size of the files. Uh, another one would be that if you premp compute the embeddings of a skill, you're actually also capturing the meaning in these embeddings, the hidden meaning that we as humans don't cannot comprehend. But rather than just describing it in text, which is fine for us to read, uh, it also has a premputation of 384 minimum to a,000 plus dimensions. And this embedding will actually hold uh things between each one of the tokens in the in the in the embedding matrix to be much more discoverable for instance by semantic search. And then this is what leads you to try hybrid search which is a combination of semantic searchs uh which is embeddings plus keyword search and and this is called RRF uh which is a type of hybrid retrieval. it performs much better because it will essentially just have both of them. Uh and it will essentially and this is uh we can I I can show you uh the example in the in the workshop because I I created this visual visualization here that explains exactly what I mean with hybrid search, right? Uh you see yeah so depending on the on the this essentially is a plot that uh combines the search capability of keyword search plus semantic search and this gap that you see at the middle is anything that's that's plotted here when doing hybrid search it will be more relevant than any of the other two. So uh as a summary uh the more like the more you can have two different types of of search. Each one has its advantages but if you combine them both you will uh effectively do a little bit more compute but then the quality of the retrieval will be better over time. Um these are like most of these I'm thinking of it from the AI agent perspective. So I'm not expecting anyone uh from this uh room to just like start building their own custom harnesses because we already have great uh solutions in the in the market right we have cloud code we have codeex each one has their own um preference by the way a show of hands for who likes pi okay less than I expected by but uh good so um I would say that I'm thinking of it as from the AI agent perspective. This what I want you to understand is that you can build custom harnesses for specific problems. And building custom harnesses doesn't to be doesn't have to be as sophisticated as creating the new clo the new clo code and then you're running all of your work in that custom harness. Rather, let's simplify the problems that you're trying to solve and then build custom harnesses that attach on to onto that. So in this case I'm thinking of um you know if you're a consultant you are my perfect uh use case or my perfect user for this workshop because you could be creating a custom harness that is working fine for a financial agent and has all the things that it needs to a financial uh use case. But then if you have another type of customer or with different types of data or with different types of constraints if you want to solve the next navir stocks problem or something uh you know those have different constraints for for instance the open AI problems the mathematical problems they need an infinite an automatic compaction or automatic context summarization because these agents don't have any human in the loop in the middle. So the like everything that goes around solving these problems have to have by default automatic uh automatic context uh summarization. It also has to have infinite patience or near infinite patience. In this case this agent loop is simplified to only eight steps maximum. All these considerations right depends on the on the problem. Yeah, I would start from scratch because that way you can you get to uh strip 90% of what you don't need. Um so I would definitely yeah I mean everything is built around the chat completions API and both Anthropic and OpenAI have created their own standards to fight off against this but everything goes around that API. So if you just think of uh the way to communicate with a model just as an additional plugin to the to the harness, it becomes much clearer that the smaller the everything is, the better it is at the end. Does that answer the question? All right. So let's do uh this. You guys uh start with the code base um with a code space. just set that uh notebook uh by yourselves and then we're gonna go I'm gonna go through and do a round and if anyone has any questions we can chat in a less uh aggressive way because I feel observed and you probably feel no pressure. So I'm going to put the pressure on you by stepping off and if you Yeah, let's uh keep going. I mean we don't have a lot of time. Oh my god. Um I time flew. Um but yeah. Yeah. Thank you. Thank you for the clap. Um thank you. Thank you. \[applause\] Uh so I thought like 15 minutes or 20 minutes went by, but one hour went by. So uh one thing uh so I'm going to leave I set this up so that you can create the code space in the hotel at home. You can I will pay for it myself. So you can, you know, use this workshop and and play with it as as you wish and I will pay for it. So don't worry about it. Just um if you want to chat about some of the agent harness concept, just come to the Oracle booth. We're going to be here until Wednesday evening. And thank you for coming to the to the session. Yeah. Okay. \[applause\]