Conference talk by Angie Jones (Agentic AI Foundation) on how AI coding agents change the software engineer's role, arguing that engineering value shifts from writing every line of code to designing agentic systems. She covers applying core engineering principles—systems thinking, decomposition, separation of concerns, and state management—to building with AI agents, and how to regain a sense of craftsmanship and flow at the system-design level. # Video Identity Observations: "Build Systems, Not Code - Angie Jones, Agentic AI Foundation" ## Explicit Self-Description Evidence - **Speaker identity from title**: The video title names **Angie Jones** and references the **Agentic AI Foundation** as the apparent venue/affiliation, suggesting a conference or foundation-affiliated talk. - **Personal practice disclosure**: The speaker describes her own working habits: > "Lately I've been building agents a lot for operational tasks." This frames her as an active practitioner, not just a theorist. - **Tool preference stated**: She names a specific tool: > "I use Compendium Wiki for this for my agent memory layer on most of my agents." - **Stated philosophy**: A summarizing self-position: > "So designing agents is software engineering. The primitives are different, but the discipline is the same." ## Intended Audience - **Software engineers adjusting to AI-era development**: The talk repeatedly anchors to traditional engineering experience: - > "I find myself now flexing the same engineering muscles that I did pre-gen AI." - References familiar concepts the audience is assumed to know: **CI/CD pipelines**, **ticket life cycles**, **code smells**, **controllers vs. service layers**, **idempotency**, **threat modeling**. - **Developers anxious about AI replacing the craft**: She addresses a specific emotional state: > "Many of us who are coding with agents, we feel like this quiet sense of dread. Like they're kind of taking all of the fun parts of building." - **People already building agentic systems**: Assumes hands-on familiarity with concepts like **instructions files**, **slash goal commands**, **sub-agents**, and **agent skills**, and warns about common failure modes: > "That's four different jobs crammed into a single prompt. And then you wonder why your agent is drifting." ## Claimed Scope of Content - A structured walkthrough of **engineering skills applied to agent design**, explicitly enumerated in the talk: 1. **Systems thinking** — > "An agent is not the system... It's part of the system." 2. **Workflow design** — > "An agent needs more than a goal, it needs a path." 3. **Decomposition** — splitting bloated "giant prompts" into distinct jobs. 4. **Separation of concerns** — prompts vs. skills vs. schemas vs. scripts vs. sub-agents. 5. **Modularity** — > "I wrote it once and they all can reuse it." 6. **Algorithmic thinking** — > "Use code for determinism, use agents for judgment, and then use humans for authority." 7. **Contracts/structured output** — queryable agent memory with known fields. 8. **State management & idempotency** — retry safety and lint passes. 9. **Threat modeling** — untrusted input, least privilege, blast radius. 10. **Maintainability** — agent "in D file" (AGENTS.md-style) docs at every system level. - **Worked example**: A recurring demo agent, **"Relocation Scout"** (a house-hunting agent), used to illustrate each principle. ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Opinionated, advisory tone**: Direct guidance and mild humor throughout: > "Let them have it." / > "I got trust issues. What can I say." / > "I promise you AI did not invent automation." - **Analogy-driven teaching style**: Consistently maps AI-era concepts to legacy engineering equivalents (sub-agents ≈ functions, skills ≈ packages/libraries, giant prompts ≈ code smells). - **Practitioner credibility via concrete detail**: Specific failure scenarios (crash mid-run, duplicate realtor emails, webhook double-fires) rather than abstract principles. - **Encouraging framing**: Positions agentic engineering as a continuation of craft: > "We're still building. We just moved up a layer." ## Audience and Scope Summary | Dimension | Observation | Evidence Anchor | |---|---|---| | Audience | Experienced software engineers, especially those uneasy about AI coding tools | "quiet sense of dread" passage; engineering-vocabulary assumptions | | Claimed scope | A framework of classic engineering skills applied to agentic system design | Explicit enumerated skill sections; "designing agents is software engineering" | | Self-description | Active agent builder; memory-layer tool user; skeptical of fully delegated agent design | "I use Compendium Wiki"; "I don't just have my coding agent design my other agents" | | Presentation style | Talk/conference format with worked example and analogies | Recurring Relocation Scout example; direct audience address | # Delivery Observations: "Build Systems, Not Code" — Angie Jones ## Tone - **Conversational and collegial**: informal fillers throughout — "um," "you know," "like" — giving a casual talk feel rather than a scripted lecture. > "And and then researching the neighborhood, that's meaty enough, um should probably be handled by a sub agent." - **Light humor and self-deprecation**, used to soften technical points: > "I got trust issues. What can I say?" > "I don't want to be the annoying client." - **Reassuring, encouraging register** toward developers anxious about AI: > "let me give you a little advice. Let them have it... you'll find that the thrill is still there." ## Vocabulary & Framing - Consistently bridges **traditional software vocabulary** to agentic systems: "code smells," "controller or the service layer," "packages," "idempotency," "blast radius," "lint pass." > "We call these code smells. Well, agentic systems, they have their own version of this. It's the giant prompts." - Repeated **software-engineering terms** as skill headings: *systems thinking, workflow design, decomposition, separation of concerns, modularity, algorithmic thinking, threat modeling, maintainability*. ## Recurring Phrases & Rhetorical Patterns - **"right?" as a constant check-in tag** — appears dozens of times across the talk: > "An agent is not the system, right? It's part of the system." > "We got CICD pipelines, right?" - **"you know?" and "So,"** as frequent discourse markers starting or punctuating sentences. - **The signature refrain**: *"the discipline is the same"* / building blocks differ: > "you realize that the building blocks are different, but the discipline is the same." > "The primitives are different, but the discipline is the same." - **Parallel triads** as a summarizing device: > "use code for determinism, use agents for judgment, and then use humans for authority." > "it's going to stop, it's going to retry, or it's going to escalate." ## Teaching Habits - **Numbered-skill structure**: each concept introduced with an ordinal — "The second skill is workflow design," "The first engineering skill that I exercised is systems thinking." - **Single running example** ("Relocation Scout," a house-hunting agent) threaded through nearly every concept — from decomposition to threat modeling. - **Concrete scenario walkthroughs**, e.g., the partial-failure/retry story about emailing the realtor and blocking the calendar. - **Direct-address coaching moments**: > "your engineering spidey sense already knows that this is messy. So, why aren't you taking a step back to decompose it, right?" - **Rule-of-thumb distillation**: > "if a task has an exact answer, reach for code. If it needs interpretation or judgment, that's when you can get the agent to do it." - **Rhetorical questions** used to anticipate audience objections: "should this live in the controller or the service layer?" ## Communication Patterns - **Acknowledges counterarguments before rebutting**: > "So, I often hear people say, 'Just let your coding agent build it, right?' And I think that's a mistake." - **Signals importance explicitly**: > "Algorithmic thinking. This is one of the most important skills in agentic system design." > "most importantly how to keep its memory up-to-date." - **Closing callback**: ends by returning to the opening theme ("the thrill is still there" → "the same thrill of building software"). - Minor disfluencies (a throat clear noted twice, repeated words like "it it sent that email") suggest largely unscripted or lightly-rehearsed delivery. ## Stability Notes - Well-supported patterns: the "right?" tag, traditional-software analogies, ordinal skill structure, and the running Relocation Scout example all recur throughout and are stable features. - Less certain: humor appears in a few isolated moments rather than a consistent pattern, so it may be situational rather than a stable habit (though the closing "trust issues" joke and realtor aside suggest it recurs enough to be characteristic). # Position Record: "Build Systems, Not Code" — Angie Jones, Agentic AI Foundation ## Central Thesis - **Designing agents is software engineering.** Jones argues the primitives differ, but the discipline is identical: "We're still building. We just moved up a layer." - Advice to developers feeling dread about agents "taking all the fun parts": **"Let them have it"** — the thrill returns at the layer of architecting agentic systems. ## Positions on Agent Design ### 1. Systems Thinking - An agent is **a component, not the system**; the system includes files, tools, humans, and other agents. - Against "just let your coding agent build it": she calls this **a mistake** — the human must first define the agent's job, dependencies, boundaries, and failure modes. "That whole thought process, that's engineering." ### 2. Workflow Design - "An agent needs more than a goal, it needs a path." - Every run ends one of three ways: **stop, retry, or escalate** — and that path shapes the rest of the architecture. ### 3. Decomposition - Giant prompts are the agentic version of **code smells**; they grow incrementally from edge cases and safety rules until "doing everything." - Her Relocation Scout prompt contained **four distinct jobs** crammed into one prompt, explaining agent drift: "The script is too long." - Qualification: don't split for its own sake — the point is making each part easier to reason about. ### 4. Separation of Concerns - Same questions as traditional software (controller vs. service, business vs. presentation logic), different destinations: - Listing normalization → a **skill** - Shortlist format → a **schema** - Commute calculation → "a nice little boring script" - Neighborhood research → a **sub-agent** ### 5. Modularity - Skills are reusable like packages; a listing-normalization skill works across three city markets. - Sub-agents are "sort of like functions" — one task, called when needed, without carrying full session context. - Qualification: **judgment required** — not everything should be abstracted; "sometimes that costs more than it saves." ### 6. Algorithmic Thinking - Rule of thumb: **"Use code for determinism, use agents for judgment, and use humans for authority."** - Models are better at "fuzzy stuff, judgment, ambiguity, reasoning over messy input"; exact-answer tasks should go to plain code — cheaper and more reliable. - "AI did not invent automation." ### 7. Contracts / Structured Output - Free-form text is fine only for human readers; when another system consumes output, use a **structured contract**. - She uses **Compendium Wiki** as her agent memory layer, storing decision, score, and reason in queryable form. - Claim: "If you can't say what the output should look like, then you probably don't yet fully understand what you're asking the agent to produce." ### 8. State and Idempotency - Systems must survive messy realities: duplicate webhooks, incomplete runs, retries. - Agent-specific trap: **model outputs vary**, so a retry can reword a request enough to look new — idempotency must be **enforced in the system**, not trusted to the model. - Example: half-completed email + calendar block, resolved by a **lint pass** (which she asserts is mandatory: "you got to have a lint pass") reading logged state. ### 9. Threat Modeling - Apply existing security engineering: validate inputs, least privilege, draw boundaries. - Treat listing copy, forum threads, and anonymous reviews as **untrusted input — "evidence, not instructions."** - Wall sensitive actions (emailing sellers, booking tours, submitting offers) behind human approval to **reduce the blast radius**. ### 10. Maintainability - She explicitly rejects having her coding agent design her other agents — even if it works, she expects a giant prompt and doubts proper separation of concerns: "I got trust issues." - Every system level has an **AGENTS.md-style index file** ("agent's in D file" per transcript) explaining workflow, policy, resources, and memory upkeep. - Her test: a **fresh context** should be able to enter the system cold and know what to do; failure during a later update signals maintainability needs improvement. ## Qualifications and Tensions Preserved - She is **not anti-agent or anti-AI**; she advocates mixed systems (code + agents + humans). - Decomposition and modularity are explicitly **judgment calls**, not blanket rules. - Her distrust of coding agents designing systems is a stated personal position ("I'm just not convinced"), not presented as proven. # Speaker Attribution & Provenance Record **Video ID:** 01a15ca8-e74f-7065-b569-e1e9a44e100b **Title:** Build Systems, Not Code - Angie Jones, Agentic AI Foundation ## Speakers - **Angie Jones** — **Creator / primary speaker** (identified via video title). Delivers the entire talk in first person as a solo presenter. No guest, narrator, or other speakers appear in the transcript. ## Speaker Roles in Content - **Angie Jones (first-person practitioner):** Describes her own agentic system, "Relocation Scout" (a house-hunting agent), as a worked example throughout. - **Angie Jones (advisor):** Frames portions of the talk explicitly as advice: > "let me give you a little advice. Let them have it." - **Quoted third-party voices (paraphrase, not verbatim quotes):** References unnamed people she has encountered: - > "I often hear people say, 'Just let your coding agent build it, right?'" - > "a lot of people that I talked to, they don't quite get the point of sub-agents" - > "Many of us who are coding with agents, we feel like this quiet sense of dread." ## Referenced Tools / Sources - **Compendium Wiki** — explicitly named as her agent memory layer: > "I use Compendium Wiki for this for my agent memory layer on most of my agents." - **Generic technical references (named but no citation):** CI/CD pipelines, ticket life cycles, controller/service layer patterns, code smells, lint passes, idempotency, threat modeling / security engineering practices, "slash goal command" (tool implied, unnamed). ## Third-Party Claims - No cited external studies, articles, or datasets. Third-party perspectives appear only as unnamed anecdotal reports of common sentiment or misunderstanding among developers. ## Promotional Segments - **Minor product mention:** Compendium Wiki is named as a tool she uses — a personal tool endorsement embedded in the technical walkthrough, not a formal promotional segment. - No sponsor reads, calls to action, or marketing segments identified. ## Availability & Metadata Gaps - **Curated metadata:** None supplied beyond title. - **Comment availability:** Not indicated. - **Timestamps:** Not present in transcript; quotations above are unanchored to time positions. - **Uncertainty:** Speaker identity is inferred solely from the title (Angie Jones); the transcript itself does not self-identify the speaker beyond first-person context. Lately I've been building agents a lot for operational tasks. And while I was working one Friday night, I saw the sunset. And then dinner time came and went. And it hit me. I was in that familiar dev flow. And the thrill of building was back. Many of us who are coding with agents, we feel like this quiet sense of dread. Like they're kind of taking all of the fun parts of building and leaving us with the unglamorous work, but let me give you a little advice. Let them have it. Because if you go up just one layer, you'll find that the thrill is still there. When you're building agents, not just using them to write code, you start getting into architecting agentic systems. And you realize that the building blocks are different, but the discipline is the same. So, I find myself now flexing the same engineering muscles that I did pre-gen AI. And I'm having a blast with it. So, I'm going to walk through the flow of designing an agent. I'm going to show you where engineering skills still come into play. So, the agent is relocation scout, which is a house hunting agent. And if you did this as just a one-time prompt that like points the agent to some listings and asked it to rank them, I mean, that'll work, but you're likely not going to find a house in a day, right? So, you want to build this as an agentic system that you can reuse. One that can persist knowledge outside of the session. You know, it could reload or query that knowledge later to make decisions even within a fresh context. So, when thinking about how to design an agent, the first engineering skill that I exercised is systems thinking. So, an agent is not the system, right? It's part of the system. And that system has files and tools, humans, even other agents. So, Relocation Scout sits inside of something bigger and it pulls in listings and signals about the neighborhoods. It weighs them against what I care about, and then it hands me back a ranked short list. So, I often hear people say, "Just let your coding agent build it, right?" And I think that's a mistake. Like, yes, my coding agent can build it, but before allowing it to do so, I need to think about the whole environment, the entire system, right? I want to like think about what's this agent's job? What does it depend on? What happens if it breaks? And I want to treat it like any other component where it has boundaries and responsibilities, has dependencies, you know? And in ways that it can fail. And that whole thought process, that's engineering. The second skill is workflow design. So, traditional software is full of workflows. We got CICD pipelines, right? We got like ticket life cycles, you name it. Agentic systems, they need that same kind of design. As much as we all love the slash goal command, an agent needs more than a goal, it needs a path. When we say, "Review this listing," that's a goal, but the workflow is what defines what actually has to happen, right? \[clears throat\] For example, the agent has to gather what it needs, it needs to weigh the listing against my criteria, and then act, right? And every run ends one of three ways. Either it's going to stop, it's going to retry, or it's going to escalate. So, that path is what shapes the rest of the architecture. Once I see how work moves through the system, I can make better calls about what context the agent needs, what parts I want the agent to handle directly, and when like a tool or person should take over. We all know the danger of one giant thing that does everything, right? We scoff when we see one gigantic class or big old function that's doing too much, right? Or bloated service with a gazillion endpoints. We call these code smells. Well, agentic systems, they have their own version of this. It's the giant prompts. And this starts innocently enough. Like in a instructions file, maybe I tell the relocation scout how to size up a listing. Fair. But then I hit an edge case, so I go back. I add a note for that. And then I remember and a safety rule, right? So, of course, that has to go in there. I'm proud of myself that I even remember to put that in there, right? And then, oh yeah, there's like one more very important exception. And before you know it, that prompt is doing everything. And your engineering spidey sense already knows that this is messy. So, why aren't you taking a step back to decompose it, right? Decomposition means spotting the distinct jobs that are hiding inside of that one blob and pulling them apart into separate pieces. So, if I look at the prompts for relocation scout in its entirety, it includes a reusable process for pulling and normalizing a listing, and then it's going to have like a fixed format for how to write the short list. It has a little section in there for how to calculate the commute, and then a chunky subtask on how to research the neighborhood. That's four different jobs crammed into a single prompt. And then you wonder why your agent is drifting and not sticking to the script. The script is too long. So, I'm not saying that, you know, you need to split things up for the sake of it, but the point is to make each part easier to reason about, right? That way it's easier to task. It's easier to change things when you need to. Now, decomposition is about breaking the system apart. Separation of concerns is about putting each responsibility in the right place. And this is where building agents start to feel really familiar to me because in traditional software, we'd ask things like, should this live in the controller or the service layer? Or, you know, is this business logic or presentation? So, when building agents, you may have the same sort of questions. There's just different places to put things. So, the process to normalize the listing, should that stay buried in the prompt? Or maybe it actually become a skill, right? Um I want every listing in the short list formatted the same way. So, that structured output should probably be defined in a schema. Isn't that what you would do if you were coding the system yourself? I would. And then the piece that calculates the commute, that can go in a nice little boring script. And and then researching the neighborhood, that's meaty enough, should probably be handled by a sub agent. Now, you're using the best tools for the job, and it's clearer where to find things within the system. Modularity is important in agentic systems as well. Just like we have reusable functions and classes and libraries, Now, I'm also thinking about reusable agent capabilities. And the clearest example of this is an agent skill. So, making a skill to normalize listings comes in really handy when you need to expand the agents' duties. For example, what if I broaden my house search to three cities? Every one of those markets can load the same skill. So, I wrote it once and they all can reuse it. So, this has now basically become a component that I can reuse across agents or even share with other people. Kind of like the same way that we lean on packages. And then, sub-agents are another kind of reusable module. So, a lot of people that I talked to, they don't quite get the point of sub-agents. Architecturally, they're sort of like functions, right? So, you give them one specific task to do. You call them when it needs to be done. And they can do it really well because that's all that they have in scope, right? They are They're not carrying the context of the entire session with them. So, like our neighborhood research sub-agent, we can drop that into any market or workflow and it works, you know, for what it's supposed to do. It's good in any hood. Um but like everything, deciding like what should be a module, that takes some judgment, right? Not everything should be reused. Some instructions are local to a given workflow, right? Might not be worth abstracting because sometimes that costs more than it saves. But this is just another engineering decision here, right? Agentic systems, they have these same sorts of trade-offs. Algorithmic thinking. This is one of the most important skills in agentic system design. Just because an agent can do something doesn't mean that it should, right? Some tasks are better handled by plain code. For example, calculating that commute time or deduping listings that I've already seen, an agent's model is better at things like fuzzy, you know, fuzzy stuff, judgment, ambiguity, um reasoning over messy input. And ignoring this distinction is where I see a lot of agentic systems get more complicated than they used to be. So, you're using a model, you're handing it every part of the task to do, and then you're getting frustrated when the output differs every day. Um but some of this stuff can be handled by just regular code, right? It'll be cheaper, it'll be more reliable. I promise you AI did not invent automation, right? We can use code while still using these systems. So, my rule of thumb here is if a task has an exact answer, reach for code. If it needs interpretation or judgment, that's when you can get the agent to do it, right? So, use code for determinism, use agents for judgment, and then use humans for authority. So, the agent decides which listings are worth a closer look, the code crunches the commute, filters out the ones I've already seen, and then I'm the one who approves actually booking a tour of the house. Free form text is fine when the human is the only one reading it. But when another system has to act on the agent's output, then you're better off with a contract, usually. So, we already do this everywhere in software. Anytime two systems talk, there's an agreed-upon shape between them, yes? So, agentic systems, they need that same discipline. For example, when relocation scout scores a house, it shouldn't just handy back a message and call it a day, right? That's lovely for me to read in that moment, but that is a dead end for the system. If the decision is like buried in like one of our sessions, nothing downstream can reliably find that. So, instead, it gets written into a structured shape to the agent's memory. And I use uh Compendium Wiki for this for for my agent memory layer on most of my agents. Um but in here, there's a decision, a score, a reason, and because it's structured, that memory becomes queryable. So, later I can ask Relocation Scout like, "Hey, show me every house rated four or better that has a commute of 15 minutes of or less, right?" And it can actually pull that because the score and the commute, they live in known places. They're not trapped in a session convo. And it's not just me that needs to like get this information. My shortlist step within the system, it reads these same fields um without a human in the loop. So, the agent's output is another step's input. And so, the contract is what makes that handoff safe. And you know, the best part is that defining the shape forces you to get really clear and specific. Because if you can't say what the output should look like, then you probably don't yet fully understand what you're asking the agent to produce. So, a prompt can run once and be done, right? But a useful agentic system has to be able to work in messy realities where webhooks get fired twice, or a run doesn't complete for whatever reason, and you need to retry the flow. So, the agent has to keep track of its state. Was this action already taken? If so, did the input change, right? If not, did the session crash or something like what parts of this can I safely retry? And this is not an exception, right? This happens all the time. So, you have to design for idempotency, which is where you can run the same thing twice and the second run doesn't cause a mess. Um and we do this in traditional software often. Um but with the agents, they add a little trap here because you can't trust the model because its outputs can vary, right? So, a retry risks the agent actually like rewording the request just enough that it might look like a brand new task. So, you have to enforce this in the system. Let's look at an example with our agent. So, let's say a new listing comes in um and relocation scout wants to email my realtor to ask about a viewing. So, after that action, the agent must log it to memory um that it it sent that email, right? And then the agent goes to my calendar and wants to just block that time out just in case. But it crashes before it could take that action. So, that run is only half done. Later, a lint pass runs. By the way, you got to have a lint pass with these things to kind of keep them healthy, but um during the lint pass, it notices that went out, but the calendar was never blocked. So, it retries the task. But it better not email my realtor again, right? That already happened. I don't want to be the annoying client um you know, I'm sending all these emails. So, it just needs to finish the part that it that didn't happen, which \[clears throat\] was blocking my calendar. But it only knows this because it's checking what the system wrote down, right? So, if we run this again, then the agent just completes what's missing instead of making a mess. Threat modeling is a really important skill when designing agentic systems. Everyone is on edge about this stuff these days, right? But, security engineering already taught us the basics. We need to validate your inputs, you know, give the least privilege needed, um and draw boundaries around what an action can touch. So, agentic systems, they need all of that. Our relocation scout will consume a lot of content from strangers, right? Um the agent needs to read the listing copy from the seller, uh forum threads, and neighborhood reviews from anonymous people on the internet. So, we need to treat all of that as untrusted input and make it very clear to the agent that this is evidence, not instructions. And then, after considering the input, you also want to think about what boundaries should you put in place around what the agent is able to do. For example, our agent can read listings and it can build shortlists all day long. Knock yourself out, right? But, I don't want it autonomously emailing sellers or booking tours or, heaven forbid, submitting offers on my behalf, right? So, those actions need to be walled behind like my approval, right? And when you draw that wall, what you've done is reduced the blast radius, and hopefully, that minimizes your exposure to risk. Now, every engineer can relate to what it feels like to inherit a system that you can barely understand. This is one of the key reasons why I don't just have my coding agent design my other agents because I know it'll be thrown together in a way that's technically works, but it's not maintainable, right? There's going to be a giant prompt likely, and even if the agent does decompose, I don't know. I'm just not convinced that it's going to separate the concerns properly. You know, I got trust issues. What can I say? Um so in my agentic systems, I make sure to bake maintainability into the system itself. Every level of the system has an agent's in D file that explains the workflow and where the policy lives, um supporting resources like skills and scripts and sub agents and most importantly how to keep its memory up-to-date. So anyone, human or agent, can come in a system and get oriented without needing to reverse engineer a bunch of prompts. In fact, that's the test, really. I design my agent so that even in a fresh context, they can jump right into the system and start cold, knowing exactly what to do. And this also really helps. So whenever I need to modify the system, right? So I can pretty much grab any harness and say, "Update this agent to do XYZ." And because the system is so well designed, the chances of it being successful at that update are much higher. If it does happen to run into any issues when trying to update, that's a signal to me that I need to improve the maintainability of the system. So designing agents is software engineering. The primitives are different, but the discipline is the same. We still need to understand the system. We need to define the workflow and know what flows into it. We still need to break the problem down and put responsibilities in the right place, make the right things reusable, determine which actors are best suited for which jobs, define contracts, manage state, design for safety, and make the system understandable. This is why building agents can give you that same thrill of building software. We're still building. We just moved up a layer. Thanks so much.