TL;DR
A few months ago I gave myself a week to ship a real, working AI agent for my consulting practice. Not a prototype. Not a demo. A tool that does work I had been doing by hand. It worked. The experience changed how I think about the buy versus build conversation that every financial institution is about to have, and where the line between operator and developer is actually drawn now. Here is the story, plus two other AI things I have shipped this year.
I am not a developer. I have been a marketing leader for most of my career. I can read code well enough to know when something is wrong with it. I cannot write a Python class from scratch and would not pretend otherwise.
A few months ago I gave myself a week to ship a real, working AI agent for my consulting practice. Not a prototype that sat on my laptop. Not a demo I could walk a client through but not actually use. A tool that did work I had been doing by hand.
It worked. And the experience reframed several things I had been carrying around about the buy versus build conversation in my client work.
What I built
The tool I built is an AI competitive intelligence agent for financial services companies. You hand it a company name. It runs.
It pulls public financial data and produces a real SWOT analysis with a financial commentary section that reads like an analyst wrote it. It then runs a technical stack audit by pulling from multiple sources to assemble a picture of what the company is using, who they have integrated with, and where the gaps are. From there it produces an M&A evaluation, with a recommendation, framed for a strategic acquirer or a partner.
Then it does the part that I think actually makes it an agent and not just a chained workflow. It opens a follow-up conversation with the user. The user can ask anything else about the company. The tool answers, but it also evaluates the quality and shape of its own output and recommends what the user should ask next. It reasons about its own reasoning to guide the user toward the question that will actually surface the next insight.
That last layer is what separates an agent from a tool. The first three stages are a multi-step pipeline. Useful, but a pipeline. The meta-cognition layer is where the agent shows up.
I built the original version in a week. I have iterated on it since. It is in active use in my own client work today.
How I built it
The thing that mattered most in the build was not the code. It was the brief.
I spent the first day writing down what the agent needed to do, in plain English, as if I were handing it to a developer. Eight bullet points. No tools yet. No code. Just the job. That document turned out to be the most important artifact in the entire week.
The second through fourth days were the build. I had an LLM with a coding capability write the first version of every component. Some pieces worked the first time. Some did not. A few were clever in ways I would not have thought of. I did not write code. I read code, asked questions, gave feedback, and iterated. The agent and I converged on a working version after maybe a dozen rounds.
The fifth day was integration testing. I ran the whole thing end to end on a real target company. It failed in two places I had not anticipated. I described the failures back to the LLM. It diagnosed both and rewrote the affected pieces. I tested again. It worked.
The sixth and seventh days were the parts nobody warns you about. Hardening (error handling, timeouts, the small stuff that turns a fragile thing into a reliable one). And then just using it. Like a normal tool. Without thinking about the fact that I had built it.
The other two things I have shipped this year
The competitive intelligence agent is the most technically interesting thing I have shipped, but it is not the only thing.
I built and launched funidea.com, a consumer-facing AI experience that helps people find local activities. You tell it where you are, who you are with, and when you want to go out, and it surfaces curated suggestions. That one was less technically complex than the CI agent, but harder in a different way. The user-experience surface was bigger. Real consumers are stricter judges than internal client work. It is live. People are using it. I have learned more about consumer AI design from running it for two months than I had from a year of reading about it.
I also built an AI readiness evaluation tool that runs a structured assessment of an organization’s posture across the dimensions that actually matter for adoption: workflows, data, governance, vendor mix, and team capability. It is not an agent in the strict sense. It is a structured AI workflow that runs when prompted and produces a defensible artifact a client team can take to their executive committee. That is the right design for that job. Not everything needs to be an agent. A lot of useful AI tools are workflows, not agents, and pretending otherwise is one of the things that gives the AI category a bad name right now.
Three different builds. Three different categories. One operator, no developer.
What this changed for me
Three things shifted.
The first was my mental model of what is automatable. I had been carrying around a list of things I thought of as “developer work” and a separate list of things I thought of as “marketing leader work.” The line between them moved. There are dozens of things in my workflow that I would have happily outsourced or assigned to a developer six months ago. Today, most of them are within reach for me directly. Not all. But most.
The second was my view of vendor pitches. Every time a vendor pitches me a product now, I silently ask myself how long it would take me to build the eighty percent version of what they are selling. Sometimes the answer is “you cannot.” That is the vendor I respect. Other times the answer is “a week, and I would own it.” That is the vendor I politely decline.
The third was about the buy versus build conversation inside institutions. The build option used to be the developer-heavy, six-month, multi-team option. That is no longer the only build path. There is a new build path that looks like a senior operator with a clear job to be done and an LLM with a coding capability. That path is faster, cheaper, and produces tools that are owned by the function that uses them, not by a vendor and not by IT.
This is a different conversation than it used to be. Every leadership team I work with is going to be having it, whether they realize it or not.
What I would not say
I want to be honest about the limits.
The CI agent I built is small. It does one job, well. It is not a customer-facing product. It is not handling regulated data. It is not subject to compliance review. The bar for production grade enterprise software, especially in financial services, is much higher than what I shipped. I am not pretending otherwise.
What I am saying is that the bar for shipping a useful internal tool has dropped significantly. The bar for shipping a customer-facing regulated product has not dropped nearly as much, but it has dropped some. The two are different conversations and should stay different.
The other limit. The skill that mattered most in the week was not coding. It was the ability to scope a problem cleanly, brief it specifically, and iterate on what came back. That is operator skill. The LLM did the typing. I did the thinking about what to type and why.
That distinction matters. The non-developers who are going to do well in this new build world are the ones with strong domain knowledge and clear thinking about what a tool should do. Not the ones who have never run a project to completion in their lives.
What I would tell a marketing leader who wants to try this
Start with a tool you would otherwise pay for or hire for. The motivation has to be real. Hypothetical projects die quickly.
Pick a job that is small enough to ship in a week. If it cannot be scoped to a week, you have not scoped it tightly enough yet.
Write the brief first, in plain English, as if you were handing it to a developer. The brief is the project.
Expect to spend the time. You are not going to build something useful by spending two hours on it. Plan a real week. The payoff is real on the other side.
Pick a problem that is yours. Do not start with the highest-stakes thing in your function. Start with the one you would happily learn on.
The bottom line
The line between operators and builders is moving. It is moving faster than the org charts have caught up to. The marketing leaders, ops leaders, and senior advisors who will be most valuable in the next two years are the ones who can ship a useful internal tool in a week, on their own, when the moment calls for it.
You do not need to become a developer. You need to know what is now within reach for you that used to require one. That awareness changes how you spend your time, how you evaluate vendors, how you negotiate with IT, and how you think about your own leverage inside your organization.
I am not a developer. I shipped a working agent in a week. It is doing real work right now. That is not the headline. The headline is that the next person in your organization who does this is probably someone you already work with.
The question is whether you give them the time and the permission.
Kevin Farley writes about AI visibility, AI readiness, and strategic growth for financial services. Read more on the blog.