
Loading summary
A
This is the Unknown Secrets of Internet Marketing, your insider guide to the strategies top marketers use to crush the competition. Ready to unlock your business full potential? Let's get started. Howdy. Welcome to another, another fun filled episode of the Unknown Secrets of Internet Marketing. I am your host, Matt Bertram. I would tell you my computer might be maxing out right now. I got too many things running. We got some cloud code going, we got a couple different agents set up, and so I probably need to close some browser windows and turn some stuff off. So if there's a little lag, guys, apologies, let me try to shut some of this stuff down. But as the conversation has moved more and more towards the agentic realm and we're talking about LLM visibility and just kind of how to think about all these things, I thought I would bring somebody on that is deep in AI agents, setups, audits, setting up that AI agent to help you help with your workflow. Sebastian, welcome to the show.
B
Thank you so much. Pleasure to be here.
A
And Sebastian's with Fountain City Tech. You can go check it out and I'll let you talk a little bit more about it at the end. But you're doing everything AI Sebastian, so I thought I'd bring you on.
B
Yeah, thank you so much. There's a lot to talk about here. So where would you like to start?
A
Well, yeah, I mean, the market's moving really, really quickly. I felt like Open Claw was a little bit of a distraction. We were setting it up, but it was having some different kind of problems. And we've just pivoted back to Claude code and just kind of now they leaked the harnesses. So, like, I think everybody's going to have a pretty good harness. I know. You know, what Facebook's doing is really interesting. Like, we've been using Mantis a little bit because you got the, you got the rag recall quote unquote from all the Facebook ads. So that's helpful. But it would be good to maybe talk about how you like a mental map on how you look at all these different, like frontier models and how you're maybe using them together. And like, even like Perplexity. I've been playing around with Comet and computer and it's really agnostic. Right. So it'll just use whatever's best to kind of build it. It's like a PO 2.0. If we're moving from the chatbot side to really the, the agent side of things, I would love to just kind of how would you paint the picture to someone that is, is around this, but maybe is not as deep in it as you are.
B
Okay, yes. I think what's coming into my head as you're talking about all those different things is first I would classify the different usage into tiering as kind of a way to kind of focus then in later on certain aspects of it. So AI assistance is kind of tier one where you're just using AI to help you along with whatever you're doing. And sometimes that might even look at how people are using Claude code, but certainly Perplexity or Comment browser. And then the next level up, tier 2, you're using AI to perform certain automations that could be on a clock that could be triggered. And the workflow automation itself might only have AI as one of those steps in the process, but there's AI, you know, somewhere in there. Otherwise it's just a normal workflow automation. Tier 3 is where I start thinking about the AI agentically, meaning it has memory tools and agency, meaning it can take its own actions either on a schedule or triggered as well. And then if you want to go beyond that, there is levels above that. But already at that third level, you have within that two different categories already as well. A and B. A would be. It's driving my computer, right. Which is more like Co Work or Perplexity. I forget the name of it when it's driving your computer. Compute, I think is that what it's called?
A
Perplexity Computer. And then like Claude Cowork is the what's driving is is shared kind of online component. And then CLAUDE code is what at least how I have it set up is driving mainly my computer. And so we're starting to put things in like Apple Minis where we're, we're playing around with like chem key 2.5 and we're. Because the token usage, unless you really manage it, like putting like a slash context or something in front of it, it will just burn through the tokens so fast. So like Tokage optimization has been the biggest area that we've been trying to tinker with because you get it to do a lot of actions. Expensive.
B
Totally, yeah. And so that second category is more the always on category. That could be like you said like a Mac Mini in your house or something like that. We, I mean we're building these systems for clients, so that's not really an option. So we put them up in the cloud. So it's like AWS EC2 servers or something, stuff like that, you know, or Google, you know, whatever flavor of system the client is in we'll just embed it into that ecosystem within. But yeah, well, you just talked about cost management. I think there's different. So talking about openclaw or these kind of systems that have agentic capabilities into it, there's so many different ways to build that system. I think the first way people think of it is, you know, maybe they're experimenting with it. They do conversations with the system, give it some abstract goal, AI goes off and tries to accomplish that abstract goal, burns, you know, $50 a day in your wallet of token usage and you're like, oh my God, I don't even know if I'm getting value out of this. You know, so we actually do. So we've been building a lot of these autonomous workers or autonomous agents and there's. We like to think of the agents kind of categorized also in terms of those different tierings that I just mentioned. So we might have one agent that really has a very specific workflow.
A
Are you, what are you using for orchestration? Are you using like LangChain or something like that? Or like I'm trying to understand what the tech stack is because I'm starting to use quad code and hooks and skills and like it's spinning up other agents underneath, like whatever it's trying to do. I, I think I'm probably teetering between, like if you framed it up between two and three, because we're just studying triggers like daily or like autonomous, like, okay, go, go run the script. And then there might be an agentic layer on decision making at some point, but like, can you back up and break down, like, what is the tech stack that you're building on? And like what are you setting up? Or maybe even give an example of something you're trying to solve for a client for sure.
B
Yeah. I will add one pre step to what I'm about. I'm going to answer your question. I'm going to say one thing first, which is I think the most important first step is to figure out what you're trying to do and describe that. I like to think of the coming up with a job description of what is going to be built and then within that, really think about the input. What is the context? What's going to be the input for each job? What is the overall general input? Like, you know, first day training on the job, what do you need to know then? What is the process? How does the sausage get made in the factory? That's a really important step. That's where your quality comes in. And not just volume of slop and then what's the output format? Right. And so once you have those three, then you can start thinking about the architecture and how you're going to accomplish that goal and what tier level you need in combination and so forth. So with that in mind, let's say that so, so we have one agent for example, that does seogeo research and build content, that feeds into a content pipeline with ideas and so forth. And so within that job description there is a whole need to understand the context of the business at heart. But then also who are the competitors? What platforms do we want it to research every week? So we have it researching all posts from all competitors Reddit X Substack, probably a few and then just a general mentions search across the whole web of who's talking about what. All of that's compiled along with documents that describe the objective. And then all the Google Analytics is read the Google search console, keyword performance, AI ranking performance is also tracked. All of that's input and then from that briefs are generated according to a format of how we want the brief to look. Those actually have strategies as well of what kinds of briefs. And then that's the ultimate output at the end of that agent is like okay, here's the things that should be written and we do also score them in terms of. I forget the name of it, but it's a scoring that we use to determine. Tier one is that it's very novel, unique content, so it's authoritative. Tier 2 is the research is going to be novel, so no one's researched this before. Tier 3 is the framing is novel, so the research and the content isn't, but the way we're framing it is. And then tier four is what we call commodity content. And then depending on the client, that type of content may never get go further. Right. That's like a barrier, like, cause that client doesn't want commodity content. Commodity meaning if it disappeared from the web, no one would ever blink an eye.
A
Right.
B
That has no intrinsic.
A
And so you're, you're using, you're using like APIs, MPCs. There's kind of some new stuff that's coming out as well as maybe some like you know, a data lake or even like a rudimentary Google Drive. And yeah, so I can, yeah I
B
can go to the technical stack next. But I think it's important to frame like what's the job first because from that then you can start moving more and more into like okay, the nitty gritty. So in order to achieve that There has to be a memory management system. So that could be SQL Database or Obsidian QMD relate. It doesn't have to be rag necessarily, depending on the volume could be just relational. And so there's that piece of it. We're building it on an EC2. Like I said, you need to have a clock that generates the recurrence. That could be a cron job, could be open claw, you know, could. I mean we're so from, from that clock. Then that's creating the occurrence. You've got the memory that then you have the skills that are developed in order to create consistency of behavior. And then we. There's a blog post on my website that talks about four things to really look at when you're building, which is if I remember them all off the top of my head, grounded. So you want everything to be state driven. You don't want the AI model to just kind of remember what the state of something is and track it in a markdown file or you want to put it either in a JSON or table or something for state driven decisions. You want to script it as much as possible. So you really don't want the AI to be thinking through how to do things over and over again. Even with a skill, it's still not. You're still going to create error rates because AIs are probable probability machines, right? So you want to create scripts that the AI actually triggers. So a skill triggers a script. The script is a set amount of code. The code runs. It's not AI anymore and it's also cheaper. Runs an operation, stores states into your data store. And the AI is just taking data back and then doing the only, the step, the only step that AI should be doing is the interpretation, right? How do I interpret this information? How do I make a qualitative decision in this case based on this data? With this context you have to manage also context because like the more skills you have, the less input tokens you have. So that's like an interesting balance right now in the ecosystem. But then, so that's, let's see, the memory agency and then the skills and tools, that's really the main components of the system, right? And then from there everything else is just driven by the input output layering. So for us those briefs are an input to another agent which then takes it further and the ultimate final output is that it just publishes it on whatever website or social media platform is connected to the system or newsletter, whatever. So that's the ultimate output. And then the input layer that can be that Research I talked about. But it could also be transcripts or video recordings or it could be even other AI agents. So we've coupled also AI fully agentic systems that build software and then those agents not only build the software but write case studies about what they did, the problems they found, how they solved it and so forth. All of those lessons learned get fed into the system that create novel content. That is then tier one for novel content. Right. Because like that, it's not just research anymore. It's not. And so you've got, you can actually have highly novel content going through your system end to end, which is like, you don't even need a person anymore to do some of that novelty in the context. Especially if it's like, you know, research driven or things like that.
A
Yeah, that, that is actually something we were talking about earlier today. Everybody listening, it's Monday and so we were, we were talking about how to pull some of that in and we haven't quite figured that piece out yet. But that would be great to talk to you more about that because that's actually what we're looking at is like, okay, the data and the data points we're producing, how do we turn that into case studies? Because that's unique data. Right? It's data that we have access to and you know, so that. Very, very cool, very cool. Well that's, I think that that's what you talked about is where the market's going and I think that a lot of agency owners are trying to kind of figure out that and are at different places and getting that done. Where do you see, like if you tried to project out, because I know it's hard because things keep changing. Where do you think everything's ultimately going at at the end of this? I've been listening to some different people
B
that talk or in 10 years, like what time?
A
Yeah, well, I, you know, everything's moving pretty quickly, like let's say like three years. Like where do you see everything converging and in three years and like where's that suppression compression happening in your mind and what is the world going to look like?
B
So the compression really is between idea and delivery. And another way to look at it would be problem solution or opportunity and action, what however you want to frame, you know, the beginning and the end point, everything in between is compressing into a slice that's going to get smaller and thinner and thinner. There's certain areas right now also that people think are relatively protected domain, you know, domains that humans have an advantage over AI. And I Think though, a lot of those are just rugs that we're standing on that are going to get pulled out from underneath us over and like subsequently, when I to the other. It's a very similar trend that we've seen with computers. You know, if you look at, you know, first we thought it could never beat a human in chess. That happened with what was his name? Kasparov. Then we thought it would never be go because the domain space was way too big. And then that happened a few years later. Then we thought the Turing test was unbeatable. That was beaten in 24. Right. So it's like we keep putting lines there and we think, oh, it'll never pass that. I think the really true. So I think humans really have. Have four main areas that are kind of the main areas to be at play with the direction things are moving. And these the four areas really to be thinking about for how humans are involved. The first is direction. That could be direction of the whole business, but it could also be direction within your domain. Right. Within marketing or within design. Some people call it taste. But you know, it's ultimately like, what is the difference between option A and B? I guess even more abstractly, you know, if my kid came to me and said, should I be an artist or a doctor? And it's like, what's important to you? You know, like, these are so abstract choices that someone ultimately still needs to make. Call it a taste decision or direction within that thing. Yeah.
A
So taste, trust, governance. And then there's like one or two others that I've started here.
B
Yeah. Trust. I would connect to the second quality, which is the interactions layer.
A
Okay.
B
People want to interact with people. And so whether that's service or sales or support or teaching or understanding or empathy and trust, and all these kind of things are kind of on the interaction layer. And so that's not going away. You know that in so far that people are actually good at that. Right. Certain types of interaction layers will eventually not like people won't even want it. You know, the time will come where you go on and you do a phone call for support and if you get a person, you're going to think, oh, God, not a person I wish I was talking to because it'd be so much better. Like, why is this company still have a person doing this job? You know, so because you're, you know, for things that are more like transactional or finding information or getting an answer. Right. Those kind of things, again, are going to just compress to the point. And I've already experienced that by the way. Like there are certain companies out there that have figured this out. And when you do support, like I've done tech support with this one company, it's all AI and it's. first I was like, okay, how's this going to be? And it turned out to be amazing. Like way better than like super fast answers, really accurate. And knew every single question I asked like instantly. And I was on and off on that support call like within minutes. Normally that'd be like a 15 minute call or more. So me ask my supervisor, right? Like is the things that like don't need to happen anymore anyway. And then so those two are kind of horizontal type jobs. And what I mean by that is they cut across disciplines. So there's compression that's on that. Compression that happens between idea and delivery will be most experienced by people in those two horizontal domains. So right now, you know, if you want to build a website or something like that, it's like things are very staged between people. It's like, oh, you have an idea? Okay, well let's get the designer involved involved to design it. Okay, let's get the UX UI study. Okay, let's, let's get the programmer involved for how long it's going to take. Okay, let's do. The tester needs to come up and come up with the test. Like all of that's compressing so that the people in these two domains of direction and interaction get a much quicker experience from beginning to end. And it's compressing already as we speak. The other direction, the other two human involvements are what I call vertical instead of horizontal. And they're just, they're the builders and the supporters. So they're the ones building and supporting and maintaining this infrastructure. That is the thing that is the special sauce. Right. Like it could be your differentiation, could be, you know, all of your moat that's created from your data, your specialized processes, the proof that you've run this a hundred times and on this particular type of problem and you've gotten these outcomes which are much better than anyone else, you know, whatever that is. They're the ones building that secret sauce, that value in there. And you know, that's all the like the building of the agents and the optimizing of them and the memory management systems and helping the AIs to replicate and to fix their problems. And they're the ones behind the glass looking over the machine floor at the robots that are building the cars. Right. Like when we went from. Because we're kind of transitioning in that in the agency world world from the world where you've got 10 people on the floor who are each putting together a different part of the car and. Right. And some people are trying to figure out how they can get a robot to pass them a tool on the floor. Right. That's like AI assistance. Can you give me the right tool in anticipation of my need? And then the shift with the agents with identifying the whole thing is like no, no, no, just get off the floor. We're going to put you behind glass and you're going to look over the hundred robots, five people look after the hundred who are building the cars. And there's still work to be. There's a lot of work to be done for those people. But it's a very different kind of job is what, you know, we're seeing. It's architecting, you know, translating things that are in people's heads to now be quantifiable into a process. Right. So there's a lot of process engineering.
A
It's, it's agent. Well, it's human on the loop, not in the loop anymore.
B
They're just slights or human behind glass is what. Right. It's like it's not even on the loop anymore. It's just behind the glass and looking at the data.
A
Yeah, well, it's just like auto approve, like set set the guardrails and like auto approve. It's. We have.
B
Yeah. We use tiering for risks and that's how we determine auto approval. So things that are low risk and that bar keeps going up. What is low risk? Yeah, those are auto approved medium. It finishes all the way to the end and then there's a checkpoint at the end. And then high risk. It's gate at the beginning and the end. Right. So that's how we kind of. There's different ways you can measure it, but that's how we do it.
A
And, and I, you know, tell you, tell me you're like, I, I feel like I have a, I have an agent set up that's just watching like making sure that even though here's the guardrails, like sometimes they do crazy stuff. Like why, why is that? Why, why would you say that? If you give it definitive like guardrails, it sometimes doesn't follow it. And I have to have like a observer agent watching that agent, making sure that doesn't, you know, hard code in, you know, API key or you know what I mean? Like why does it do it even if you tell it not to do it like, like I, I would, I would say it's like data hygiene. But you know, if this is a new project, like there, it's like it shouldn't be an issue, but sometimes it is.
B
There are different reasons that could be happening. I'm not going to be able to tell you one reason without actually diagnosing your particular case, but one reason I'll just go through a bullet list and we can dive into any one of them if you want. One of them could just be the model mismatch. You might have a model that's just not good enough for that. If you're using haiku or something equivalent to that. They're very pattern based. They're looking for patterns and they replicate them rather than thinking through problems. Then the mid tier model, like Sonnet, they're better but they can definitely, I've seen them definitely what you're talking about like hard coding values in like, oh, your test case says that in this test it should come up with this answer. So I'll just hard code that value with a magic number in the code. And all of a sudden your pat. Your tests pass and it's like, oh my God, I can't believe you just did that. You know, that's not the goal of the testing whatever, but another category. So you know, you might just need a stronger model, right. That sometimes that fixes these things. Like OPUS is very good at following instructions and we've been experimenting a lot also with GLM 5.5.1.
A
So you just think if they're getting better, like they're just gonna.
B
That's one, that's one vector, right. Of like possible reasons. Another is context and memory management. And, and you could also include skill management and tooling as like all part of that category. So if you see for example and this. Oh and then the next thing which ties into this is how do you approach problems when you see them? So whenever we see a problem we always ask ourselves, you know, the question isn't why is this model making this problem? It's what can I do to improve the system to make sure that this problem doesn't happen again. Right. And so that framing is really important to take. And sometimes I see people just get start writing angry messages to the AI or tell it more sternly how it should be doing its job, you know, and like that might get you some results, but it doesn't mean it's, it's going to happen again to you, right? Because what you're not, you have to really be thinking about system Design. So, you know, so take a crash course on, like, how to be a good system designer and look at what are, you know, what are the top five, 10 things you need to learn to be that, to embody those core qualities. And then that's how you should be approaching the problems. So if you have an AI that's not following the instructions consistently, maybe you need, you know, you can even ask the AI, do you have a good skill for this? What skill are you using? Or you can look at the log of how it did it. Maybe it tried something and it got an error, and then it tried something else, got an error, and then it tried a third thing and then it found the answer, and then it took that, and then you can kind of watch what it did. And if you're seeing that it's kind of bumping along or way like a pinball machine, you can go through that with the AI afterwards and you can streamline it with a skill that tells it immediately the correct way to do it so it's not having to bump around like a pinball machine. Sometimes people, the prompt or the system prompt or the thing that they're writing is not actually phrased in the way that is the most effective. As models get stronger too, you really won't be focusing more on why you want to be doing something thing which is often forgotten. That you need to communicate that to the AI and what the desired end goal of it is. And not just the steps like I want you to do, step one, step two, step three, step four, that can work. But especially as you get to stronger models like Mythos, that's coming out, you want to really be making sure that you're guiding these AI systems with goals and purpose of, of what they're trying to achieve, because that helps the AI a lot, to make sure that it's not going to shortcut you with like a magic number in there. Because if you're telling it like, we want to make sure that this works for all possible values of this variable in this, you know, here's going to be some test cases. Make sure it passes those tests. That's very different than saying, here's a test, the answer should be 1.5. Go test it. And then the AI is like, oh, we want it to be 1.5. Let's hard code that thing in.
A
So I saw a podcast interview with the founder, and he was just like, I use plan mode, like for almost everything, right? To give it those objectives to answer those questions, which I think are extremely helpful. One of the things you made me think of was like, how are you solving persistent memory? And you mentioned Obsidian earlier and we've started to toy around with that. I'm not like an advanced user, but I would love to know kind of like how you're solving the persistent memory and kind of like connecting it all together. Because you only, like you said you only have so much in the context window and when it compresses it, it kind of, it. It loses stuff. And you got like the heartbeat component right there.
B
There's just like with so many things I can say now because you keep mentioning new things.
A
I know, I know, I'm sorry. Like, yeah, clean it up for me. Clean it up for me. The listeners of.
B
I do. I do want to also just touch base on plan mode because plan mode is awesome when you want to be building things. But there's a very big difference between planning, which is to build something versus using something. You can't use plan mode to use an system. So just want to make sure that that's clear. But in terms of building, there's a lot I could say around plan mode, how to make that even more effective.
A
That's a different conversation.
B
I don't know. We just want to.
A
Let's go down some rabbit holes of like and let's like actually give some context. So let's talk about the plan and we'll move into.
B
Okay, so there's. First of all, there is a big debate right now between where to get most leverage and plan in. In the planning and execution. When you're doing agentic coding, so you're using a team of agents to write and execute the code and self test and all that kind of stuff. Right? So it's not AI assistance work. I'm just having it write one file function of time, one class. It's like doing the whole refactor or the whole project. Those three points of contention are should humans be spending most of their time during the planning? Should they be spending most of their time during the code review? Like some people are saying right now, some people are changing their mind too, that some people used to say read all the code. That's right, sorry, read all the plan, don't read the code. And then those same people are now saying, we made a mistake. Take you don't. Don't read all the plan, read all the code. But there's a third place to also there's a third philosophy or third camp, which is review all the tests. Right? So that's where you really need to be putting all Your energies at the end point is the testing. So you're kind of doing a test driven setup. So the I do think personally that that contention of where to put the effort between the three, I think of it, you know how you have those min max absolute points on curves where if you had a two dimensional graph and there's like a bell curve and you want to kind of be an optimal value with a peak somewhere around there. But because it's three points like time, sorry, testing, code and planning, it's actually in like a three dimensional space between those three and like where do you put most of your effort? But I do think that that whole question will go away as models get bigger, better and bigger. There's still so much to be done around memory and context, which you're hinting on. I think that's really a big gap right now that companies will most likely start having to focus on a lot more in the coming year or two. But in terms of the planning when you're doing it. So the way we build plans is first we write up a, either a product design requirement document or an ADR and architecture design requirement document. Depending on the refactor or the code that we're writing, that could be somewhere around 2 to 6,000 lines of planning that is created. That's a whole process. This is where you're putting a lot of time in, at least for us, is the planning. Our planning time has gone. It's like way higher than it used to be. Right. We used to just like write a, write some specs, figure out some stuff and start coding. Right now we're spending about double the time than we used to historically on all of this planning stuff. And so you, so we do that first planning up front, then we take that document. We're not done with planning because then we take each phase or each section of it and each of those is then broken down. One of the things we tell the AI is write it as if a junior was going to write this code, right? Like how give the junior enough information that they know exactly what they need to do do for each of these steps. There's more to it too, because you really have to think about edge cases and how you're going to test things and validate and how are you going to get the AI to do all of this work without a human needing to be involved with these steps? Sometimes you have to build bridge. There's like mini projects that have to happen to just build those bridges or there's self validation loops. You build all of that out. And then from each of those documents then you build work order collections which are breakdowns of context. That is a living document plus a planning which is a living document. And then actual individual tasks which is also living documents to living meaning that they're edited as they're being used. They're not just static. And then those collections and there are different frameworks but this is kind of the most simple one. Those are then passed on finally to a team of agents that then has their own state driven control system that I was talking about to make sure that things are grounded. So that and they have antagonizing objectives is also important too. Like you want the tester whose goal is to find as many bugs as possible and they get pats on the back or best fit points or however you want to look at it. And the developer wants of course to code successfully. And then the task manager wants to make sure that everyone's proving that they're doing their jobs. They can mark them all off. So every single role in it has their own objectives and some are antagonizing. And then they go through all of those self check and rapport. And then you just need and then from there you as you make the system more and more sophisticated and resilient you can accomplish larger chunks of work at a time before a human needs to even go and start reviewing it. So if my run for five minutes in the background when you're building confidence but then eventually it's running for like 30 minutes or more in the background as it just crunches through these different documents in series. Now planning one off planning mode in Claude code that I would say I kind of view it as like one step above AI assistance because what you're doing is you're basically doing a one shot job in air quotes on a particular function or feature or mini refactor. But there's a limit to the scope and scale that that can accomplish on its own. But it is definitely way better than just a one shot prompt in it. But even the plan mode needs supporting memory and skills and things like that in order to make sure that the plan is grounded in truth and doesn't just have assumptions surface level assumptions in it. That's that's kind of the devil a lot in the detail with a lot of the plan mode is the AI has is sitting on top of a very large quote code base reads three files but doesn't read the other 10 it needed to read. Does a plan based on assumptions and what the other files does and all Of a sudden it's completely gonna just screw you over when it goes through. You know, we've seen those problems happen. So, you know, plan mode can be amazing, but it can also be insufficient.
A
No? Oh yeah, no, I think it was kind of like a bare minimum. Like if you're gonna like just a one shot prompt, like if you, if it's not really elegantly engineered, it's not going to give you the output you need because there's a lot of conversations I guess on social media of like all these tools that are just kind of wrappers anyway. And it's like build me a whole app and then it breaks and it's like you can't build a whole app with one line of code. And then you got to think about, well, how many users are going to go through this app at the same time. Because if you scale it up, you got one function processing at a time. It's not going to be super useful. I know I'm pivoting all around. I have so many questions for you. But that's been some of the debate with a couple client projects that I got pulled in on. Is okay, like we want to vibe code something and it's functional but there's some security concerns. What kind of data is going to go through it, how many users it's going to be. And then like, okay, can like base 44 or so some of these tools replace a enterprise system, right? And it's like, no, use it to create the MVP and then at a certain point switch it over to a developer. And I'm starting to see with, with these agent systems it's like, well, they can code it up like, you know, like, like okay, maybe you're not using this tool, but these agents, if, if, if they have sufficient information and I get it goes back to the memory. I feel like the memory is that big issue right now. But I mean they can code it in whatever you want to code it in. Like you can build a plugin, you could build it with a similar backend. Like if you're building a WordPress site, you could build a similar looking WordPress backend. Or hey, let's just use the command line or the terminal to do all the work and let's not ever touch the site. There's a lot of these discussions of I feel like it's when digital cameras switched over to a new technology and it's like you got to make a hard switch at some point to create different processes and do things differently because a lot of people are Augmenting the old way, but there's a new way of doing things. And where is that switchover point and also the maturity level of what these things are doing? I, you know, like do you have to hand it off to a full stack developer to build it out or you know, can these agents build it where it's enterprise ready? Like what's happening with SaaS? There's a lot of questions in there, so feel like to answer whatever one you want.
B
Sure. So what I would say is, I mean talking about that last thing you were just mentioning around the full stack development developer.
A
Yeah.
B
The way we've seen. So we made a rule for ourselves first experimentally back in December which was can we do this new project never writing a line of code. And it was a pretty. It was a hydraulic system simulation code refactor, you know, a meaty thing. Not just like something you could just spin out as a vibe code thing in an afternoon. And back then it was also pre opus 4.6. I think it was 4.5 at the time or something magical that happened with 4.6. But that comes later in my little story. But man, it was like the first month was like painful because we were just. We had this rule and we're trying to go through it, you know, regardless of how to learn how can we get this thing to, to be as good as us doing it by hand, but not right. And so, but now with the way things have progressed and all the things that we've learned and then also 4.6 which did like this magical kind of frosting on the top and like really brought it even more to reality, at least for us. Like it's kind of over the whole idea that you write code by hand. You know, of course if the client comes over and it's just like I need to change something quickly. I mean maybe you just change the line of code or maybe you just one shot that one little thing. But any kind of major refactor, major project, we're seeing that it's done way faster and has less problems than when people are doing it. By less problems, I mean less bugs, you know, so I mean that's kind of a big kind of milestone is. And I'm by and less bugs can compared to like let's say the average programmer. Right. I mean of course there, there's going to be senior coders out there. We're going to still beat these AI systems today. I don't know how long that's going to last. Honestly, like probably a year from now that might not even be true anymore, but at least right now certain senior devs can probably out compete the AI still, but probably not on speed, but more on bugs and broader thinking of impacts and things like that. So there's still some, a little bit of a moat there. But yeah, in terms of enterprise ready software and so forth, you do need somebody who is that brain who really is thinking through, you know, what are the security levels, how are we going to test this, how is it going to integrate when we're done with feature one, what's coming next, how do we not paint ourselves into a corner? All this kind of like broader level thinking that AI is not capable of doing that. AI is terrible at asking tangent of questions. You know, it's like the AI will take a task and it will converge on what is the most likely output or answer for that particular problem. Problem. In fact, people get really pissed off if the AI comes back at them and throws something that they weren't wanting to do. You know, this is just popping in my head, but I remember last year, this was a while ago, but someone posted on social media that they were asking the AI to write some code for them. And instead of writing the code, the AI responded back telling them that they think the AI said to them, I think instead of me writing the code, you should really go off and, and read these things to become a better programmer. Probably because what they were asking them to do was just like flat out wrong. And the person was so pissed off and everyone responded to that social media post saying like, oh my God, this is the end of humanity and AI is revolting against us and stuff like that. But it's like, you know, like people don't even want these systems right now to be thinking, you know, there's this risk that we don't even want them to not obey us, right? To say to us like, hey, what you're doing is probably you haven't thought of this thing. Like are you sure we should be doing this? Like people would be like losing their mind if it does that. No, it should be.
A
Well, I think that that's, you know, you go back to like different of these different models and like how they're, how they're building them and what they're trying to achieve. Because I feel like Claude is pushy, like it's pushy it like, and I'm like, hey, you don't know all the facts. Like let me give you some more artifacts. Especially kind of more before we switched over to kind of the agentic era. But. But I'll tell you, chat gbt, unless you turn off, like, nice guy mode or you, you know, you have a devil's advocate going on. It's just gonna tell you what it wants. Like, it's. And that. I think that that's the approach. And people started using chat GBT and they're like, oh, I'm always right and I'm amazing and all this kind of stuff. And then you switch over to Claude and Claude, like, you know, or Grok will tell you, like, what it is. And then you're like, whoa. Like, I didn't expect you to say that. Right. You know, and etc.
B
Yeah, I mean it. You can take the analogy also with people when they hire people, right? If I hire someone for 15 bucks an hour, 20 bucks an hour, whatever, and I tell them what to do, most people don't want that person saying to you, like, are you sure this is the job I should be doing? Right? Like, they just. You just want the person to do the job. Then you pay someone $200 an hour and you tell them what should be done, and they come back and say, actually, you should be thinking about these things, right? All of a sudden, you really want to hear that. And if that person doesn't push back, you think that that person doesn't know what the hell they're talking about thinking, you know, so there. This also, I think, is translating across models and different price points. And the only. This is going to. This is a bit controversial, but I think you could totally take giving an idea here to OpenAI. You could totally take your model, the mass model, and just only remove one training thing, which is that when you're training the model, don't make it please the user, but instead be more contrarian and pushing back more and then make people pay more money for that and they will take that model more seriously because they're paying more money for a model to actually push them rather than just please them. But, you know, but most people want cheap and free things to please them. They don't want them to contradict them. So there's this psychology in that as well.
A
No, it's. It's super interesting. Okay, so we have a few more minutes. I would love to talk a little bit more about kind of how you think about orchestration. Because, like, a lot of how I was thinking about orchestration before was like, okay, one agent specializes in one skill. And now you can start to add a lot of, like, skills to one agent and make it like a super agent, right? But there still is different roles that you want to define for it to do. But how? I was thinking about orchestration before and even like some of the books that I had bought and read, like one third of the book is maybe useful now and two thirds, it's like we've already passed everything it was talking about and so we're on kind of frontier stuff. When you're setting up these systems, how are you thinking about orchestration today?
B
Yeah, so there's two parts orchestration, there's the human orchestration part of it, and then there's the agent to agent orchestration. You're talking about more the layer, right?
A
Yeah. Agent to agent.
B
Yeah, yeah. So I would say two things. First is the architecture of it and the second is the solution, problem driven part of it. So if you're getting inconsistent results from a process, the process, you might be putting too much agency on one agent and you need to split that up into sub agents or sub steps and you might need to formalize them to become more of a linear process rather than a qualitative decision matrix. Right. So one problem I see often is one agent will be given too much, too much space, too many skills, too many things it could do. And you're asking the agent to then make broad decisions instead of making it more controlled. And so if you can, one quick solution to that would be you've got an agent which first does a decision on what type of request is coming in. Is it a, you know, secretarial request? Is it a booking request? Is it a research request from my human, whatever it might be, or from the clock or from some other input, whatever it is. And then it dispatches that to another agent which then specializes on just that. And then that state script driven element to it is also important there. Splitting it up can also help you with that memory management context. I know we probably may not have time to get into that. I know that was one of your questions, but memory management is of course really important right now. Context management, context firewalling as well between agents.
A
And then you talked a little bit about the bridge, like building like little bridges, like can you give an example of that? Maybe.
B
So if I'm, I hope I'm talking, when I talk about, Stop me if I'm going down the wrong path here with the bridge. You're going over the wrong bridge for what you're talking about. But I would. Are you talking about like the, for example that SEO Geo agent who comes up with a brief and then the connection to the next agent?
A
Yeah, yeah, like, like you have to build a little of the brief brief to do the bigger project. Like giving people an example of what that is. You, you can start to separate out what's being done and you're connecting like maybe two systems together, if you will.
B
Yeah. So going back to my analogy of thinking about jobs, so if you think about a job and the domain of what that job is and the knowledge is needed for that, that gives you a contained space. That job may sometimes need to be split up if you're putting too many jobs into it. You know, sometimes I'll look at a job description for human, and when I look at it for an AI, it's actually three jobs because it makes more sense that way. They're just trying to hire some kind of unicorn, do these multiple roles altogether. And then, but then just like in traditional systems, some of the most important parts is the connectors, the edges between systems, those bridges, those gaps or APIs, whatever you want to call about it. And so you need to formalize the output to the input of the next system and how you're going to control for handover and errors and expectations and checks between these systems. One sec, I have to clear my throat for a second. Okay, sorry about that. And my, and my coffee cup's empty, so I couldn't just equate, liquidate my throat there. Liquidate, liquefy, I don't know, whatever the word is. Lubricate. That's what I'm looking for anyway, so you have, you have to look at that bridge point and then there's different ways you could do that. You could use an inbox system where you just talk to each other. You could use a folder based system where they scan those folders. You could use more like a spreadsheet.
A
Right. Like you drop it on a spreadsheet,
B
could be a database, I don't know. It depends on how sophisticated it needs to be, how much you need to scale it.
A
Because I was like building stuff that I was having Perplexity create and I want, wanted it to talk to Claude code and the best way I could figure out how to do it is dump everything into a spreadsheet and then cloud code recalled it. Like I was trying to get them to talk to each other, but I just had to like drop everything in a document and then, you know, have it.
B
When you say complexity, it's just you using Perplexity browser.
A
And so, so Comet, you can spin up multiple agents at a time to
B
do like different research in there. Okay.
A
Yeah. And so, so But I was trying to get them to talk to each other and I, I was just dropping in a spreadsheet and then recalling when it was updated so it would check it and if new information was checked it would pull it. It's kind of how I got it set up. But it's pretty rude when we're used, yeah.
B
When we're using Perplexity because it's great for certain. It's really good for certain things. We're using it as an API tool for an agent that it's itself has access to databases or memory or whatever. So we don't need to that whole kind of what you're talking about. We don't end up having to deal with it because Agent I don't know Bob, let's call agent Bob. But Bob has the API for plexity, does research with there, gets data back, stores it either in a JSON file or a table or Supabase or whatever kind of needed and then the next agent can just pull straight from that system. So it's just all within the same, same ecosystem.
A
Yeah.
B
Translate across a third medium.
A
Got it. Yeah. Awesome. So I, I, I do have a hard stop on the hour. I would love to kind of, I know I, I jumped around. I, I'll definitely have to have you back. I, I really enjoyed our conversation. I know we were talking some.
B
Yeah.
A
Same philosophical stuff. Yeah. No, you try to talk to somebody on the street about this sometimes people are like, what are you talking about?
B
Oh, totally.
A
No, maybe. Is there anything in the course of this conversation that you thought might be really valuable to just add to this conversation here and then if you could share a little bit more about what Fountain City is doing and how to get in touch with you. You talked about some blogs you're writing and that would be phenomenal.
B
Things that weren't discussed. I mean there's so many things that could be talked about. You know, the security and how are you handling that? There's scalability, there's don't drop your, don't
A
drop your API keys right in the prompt. Guys don't do that because it's going to get processed like there you got it. You got to set up a file or something like that where it pulls from. Yeah.
B
Yeah. So there's a lot to talk about there. Yeah. I think every, everything I can think of is just rabbit holes. So it won't bring up like too many things that haven't been talked about. But in terms of me, us, Fountain City. So FountainCity Tech is the website and our clients right now are actually a lot of agencies are hiring us to build either systems for themselves and, or for their clients. Sometimes one person also we're talking to right now is to build a vertical stack system. So it's. They have lots of really tiny clients, like 80 clients in one vertical. I won't name it, but you know, imagine it could be like, I don't know, plumbing or services.
A
Yeah.
B
So some kind of services industry or some kind of industry. And so then you, you get this economy scale because you can have one research pipeline and then it generates a whole bunch of topics which then get interpreted and resegmented for different writers for each of the different subdomains. So we're doing a lot. Yeah, like I said, with agencies direct to client and then these, these integrated verticals or multi site hosted stuff. So that's kind of one part of our business. And then the other part is doing what I described with the agentic coding because we're able to. And then those projects tend to be building systems that have AI in it. So like right now we are two biggest project for running is one is a voice system where it listens into enterprise conversations and then gives very. And then listens into these enterprise leaders speaking and then gives very thoughtful input to kind of help them to think broader or think deeper or think in a new way about the problems they're bringing up. It's a very interesting project. And then the other one we're doing right now is on a data intelligence layer. So we're connecting together. People come to the website from all different possible paths, everything interact on the website and then everything they've purchased or thinking about as they touch all these different systems and then building that out into on demand charts. Being able to predict, you know, who, who should they go talk to first and then being able to AI talk to the data and stuff like that. So that's another cool kind of project we're doing.
A
So I'm using a tool called R A F A N A. Are you familiar? I don't even know how to say that.
B
Can, can you pronounce that? Sorry, Grafna. Is that what you.
A
Graphna? Yeah, Graphna. Basically to, to. To take like that data intelligence layer that you're talking about, throw it into these kind of dashboards, you can look it up. You would, I don't know what you're using. I would love to have a tools conversation with you.
B
We're using grist on that one.
A
Okay.
B
Which is another G letter. It's not graphna it's grist. I was almost wondering if you're talking about that. But yeah, we are using that right now as kind of a. It's. It's kind of like a. It's like a spreadsheet and a database had a baby kind of. Okay, cool thing. So it's a bit like a spread or it's like a. Almost like a. What was that thing called? There was the spreadsheet thing that was popular with project managers a few years ago where it's like super spreadsheets. It's kind of like that because this client really likes spreadsheets. So we're giving them that as like a low cost kind of middleware to all of the data collection. And then from there, because it's essentially database, we can connect it to anything we want. Visualization, AI model, context and stuff like that.
A
Yeah, this would be like the next generation of like bi or looker or something like that that's more interactive and you can pull it more data. No, Sebastian, this conversation's been. Been awesome. So where are you putting out new. New information? You talked about your blog. Is there like. Do you have socials stuff? Yeah.
B
So LinkedIn, my account's probably the best. So just my name on LinkedIn and YouTube. I. Things have been a bit slower on YouTube recently, but I. It used to be once a week, now it's kind of like once a month. But I'll probably pick it back up a little bit more. I just have some speaking events coming up. So I've been. And this launch of this kind of virtual digital agency product has been very time consuming. So I've been more focused on that recently. This kind of autonomous agent system. Anyway, YouTube, LinkedIn, the blog on our website is almost daily. Blog posts on everything related to this, like, you know, from security to implementation, stumbling over my words. And then what else? There is a newsletter also in Fountain City. It's pretty. It's not very often that we newsletter out so you won't get overloaded. But you can sign up for that too on our website.
A
Awesome. Well, we'll definitely have to have you back on. I have so many more questions for you and I like all the stuff you're doing. If anybody's listening, this is kind of where. Where it's all going and so you need to, I. I think really understand the taste. Is that what we said? Is that what we settled on? Like the taste of kind of where you. What is your secret sauce? Yeah, like why people should hire you. What are, what are you doing I think that that pendulum is going to kind of swing back because a lot of these things are going to be compressed. And, you know, programmatic is just, you know, like, the world's changing, and so it's hard to stay on top of all this stuff. Sebastian is great to have you on. Thank you for being here, guys. Go check out what he's doing. I think, you know, this is the future. Until the next time, if you want to grow your business with the largest, most powerful tool on the planet, which I would have said is the Internet, but, you know, I would say it's now agentic agents. Keep listening to this podcast. We'll keep bringing on some of the people in the industry that are moving it forward. Thank you so much for your time. Until next time, my name is Bat Bertram. Bye bye for now.
B
Thank.
The Best SEO Podcast: Defining the Future of Search with LLM Visibility™
Episode Title: Agentic AI For Marketers With Sebastian Chedal
Host: Matthew Bertram
Guest: Sebastian Chedal, Founder of Fountain City Tech
Date: April 19, 2026
This episode dives deep into the fast-evolving world of AI agents and their transformative impact on marketing, SEO, and digital operations. Host Matthew Bertram and AI systems architect Sebastian Chedal explore the technical and strategic frameworks for building agentic systems designed for marketers and agencies, covering everything from architecture to orchestration, cost, persistent memory, and the human roles that will remain vital in the coming agentic era.
Pre-Step: Start with a detailed “job description” for the AI agent—input, process ("How does the sausage get made?"), output.
Components Include:
Tech Example [09:52, Sebastian]:
Sebastian identifies four critical human domains in the agentic era:
On future roles for humans:
“It’s architecting, translating things that are in people’s heads to now be quantifiable into a process.” — Sebastian, [19:51]
On cost & memory management:
“Token optimization has been the biggest area that we’ve been trying to tinker with because you get it to do a lot of actions. Expensive.” — Matthew, [04:31]
On orchestration & specialization:
“One problem I see often is one agent will be given too much space, too many skills, too many things it could do...You might need to formalize them to become more of a linear process.” — Sebastian, [42:50]
On context/memory as a bottleneck:
“There’s still so much to be done around memory and context, which you’re hinting on. I think that’s really a big gap right now that companies will most likely start having to focus on a lot more in the coming year or two.” — Sebastian, [28:24]
On agentic software development:
“Any kind of major refactor...we’re seeing that it’s done way faster and has less problems than when people are doing it. By less problems, I mean less bugs.” — Sebastian, [36:46]
On agent-to-agent communication:
“...just dropping in a spreadsheet and then recalling when it was updated so it would check it and if new information was checked it would pull it...it’s pretty rude when we’re used...” — Matthew, [46:23]
This episode is essential listening for marketers and agency owners who want to understand the new rules of engagement for AI-driven SEO and digital marketing. The rapid shift to agentic models compresses production, redefines human work, and offers competitive advantages to those who learn to architect, orchestrate, and leverage these new systems. If you’re not visible to the models, you soon won’t be visible to the market.