Build in Public: Week 4. The Messy Middle Of Building An AI Agent

#ai #buildinpublic #development #saas

This was supposed to be the week of a polished demo video and a clean “here’s how you use our API” walkthrough. Instead, it turned into the week of staring at half-finished pieces, poking at logs and wondering why we voluntarily chose Instagram as our first supported social network.

If you remember last week’s post, I was feeling pretty optimistic about discovery methods and how you can mix different approaches. In theory it does work. In practice it works just enough to keep you going, but not nearly as well as you hoped when you first mapped it out and convinced yourself you’d cracked influencer search forever.

And this is exactly the part where motivation gets weird. Weekly posts sound great until you realize each week expects something polished, while the actual project is still a pile of experiments, half-successes and “why did the model hallucinate a bakery that literally does not exist?” moments. The LLMs get confused, APIs throw attitude and life is life. It’s surprisingly hard to keep shipping when the thing you’re building is technically working but also kind of fighting you at every step.

Another factor that complicates this stage is the dynamic of working on a side project as a partnership (even if it's your own brother). There isn’t a built-in structure around you, so the pace and direction depend entirely on the two of you. One week you’re perfectly aligned and the next you suddenly realize you’ve been solving slightly different problems or moving at different speeds. It’s a very different rhythm from a regular job, where roles and expectations are already defined. Here you have the freedom to shape everything yourselves, which also means you have to constantly realign even when both of you are tired or distracted.

But even in a week like this, things did move forward. Before getting into this week’s progress, it’s worth revisiting the idea that Wykra needs two distinct ways of handling creators. One mode is all about speed: give people a quick shortlist that matches their brief well enough to start browsing. The other focuses on depth: when someone finds a creator they care about, the system should be able to switch gears and produce a much richer, slower, more detailed analysis based on the full dataset.

With that in mind most of this week went into shaping the “quick” part - the end-to-end search flow. The agent now has a clear path from a natural-language request to a structured result:

A user sends a brief. Something human, messy and vague: a location, a niche, a follower range.
The system turns it into a task. The request gets dropped into a background queue so it can run independently of the interface.
A worker picks it up and interprets the brief. It sends the raw text to a context-extraction model using anthropic/claude-3.5-sonnet, which pulls out the useful bits - niche, geography, audience size - and turns them into structured signals.
The worker runs a first discovery pass. A strict prompt goes to perplexity/sonar-pro-search, asking only for real, verifiable Instagram profiles found through trustworthy external sources.
The system fetches profile data for the first pass. Instagram URLs from this strict pass get sent to Bright Data to pull actual profile snapshots.
The system checks the results. If there are too few valid accounts after this first pass, the worker switches to a broader fallback search.
The worker runs a second discovery pass. A more flexible prompt scans a wider part of the open web - websites, Linktree/Beacons, cross-linked socials, press mentions - still keeping only URLs tied to real profiles.
The system fetches profile data for any new profiles. Only Instagram URLs that didn’t appear in the first pass are sent to Bright Data to collect additional profile snapshots.
It merges and cleans the results. Duplicates are removed, broken links disappear and only valid accounts make it through.
A short analysis is generated. anthropic/claude-3.5-sonnet produces compact summaries and basic engagement signals.
The completed task is returned. The end result: a processed, ranked set of creators.

If I had to explain this quickly, I’d probably just draw it like this:

You can take a look at the actual processor code here: https://github.com/wykra-io/wykra-api/blob/main/src/instagram/instagram.processor.ts and if you follow the README (https://github.com/wykra-io/wykra-api/blob/main/README.md) you can even run the whole thing yourself. But if that sounds like too much effort, don’t worry I’ll just show you the videos.

First, here’s a quick walkthrough of how to spin up the project and get everything running locally.

Next, we trigger a search task by sending a curl request to /api/v1/instagram/search, grab the task ID from the response, and then check its status with another curl to /api/v1/tasks/{your_id} the video below shows exactly what that looks like.

curl --location 'http://localhost:3011/api/v1/instagram/search' \
--data '{"query": "Find up to 15 public Instagram accounts from Portugal who post about cooking and have not more than 50000 followers."}'


curl --location 'http://localhost:3011/api/v1/tasks/{your_id}'

The video shows exactly what this flow returns and I’ve copied the response below as well just so you can see that it does, in fact, return something reasonably shaped.

So that’s our first flow. Now let’s take a look at how the analysis flow works. Here’s the curl I used:

curl --location 'http://localhost:3011/api/v1/instagram/analysis?profile=baker_miss_by_carol'

The video below shows the call in action.

And here’s the response we got back.

As you can see, this isn’t exactly brain surgery, but it’s also far from perfect. There’s a lot left to improve: adding Google SERP is high on the list and I’ve been reading about exa.ai as well. I’m also considering a fallback where, if the prompt language doesn’t return anything useful, we automatically switch to the local language. Not every Lisbon pizza blogger writes in English, so it makes sense to ask in Portuguese when English comes up empty.

Overall, I can see us drifting into the testing phase (or the panic phase), which means it’s time to think about observability. We need proper logging for what we send and what we get back, and we definitely need some regression tests. Otherwise it’s impossible to tell whether adding Google SERP will actually help or quietly make everything worse. In short: the moment has arrived.

We need metrics!

If you want to support the project, feel free to ⭐️ the repo and follow me on X — it genuinely helps and keeps me motivated to keep building.

Repo: https://github.com/wykra-io/wykra-api

X: https://x.com/ohthatdatagirl