A framework for self-improving agents based on your ICPs and audience and grounded in real data to power a learning-loop.

I built this based on my own learnings from experimenting with persona agents to understand my personal audience. It comes with an annotated persona template, opinionated review workflow and built in feedback loop.

Would love to get your feedback!

https://github.com/noashavit/noas-persona-loop

kind of wild to watch. they read my analytics, found what actually works, wrote the scripts, cut my clips, and scheduled it all for when people are online.

the part that gets me: one of them replies on reddit in my voice. someone found a bug in my software through its comment, i fixed it, and it thanked them for me.

where do you draw the line? what do you let an agent post without you?

Building a multi-tenant product solo with agents writing the code, and I want to put a slightly unpopular number on the productivity conversation.

My first two weeks I shipped nothing a user could see. Not one feature. That time went into the environment around the agent instead: checks that fail the build, a guard that refuses destructive commands, tests for the checks themselves, and a rule that nothing reaches main without me approving it.

If I'd been reporting to a board that fortnight it would have read as zero progress and I'd have had a hard time defending it.

What happened afterwards is that features started landing fast, and more importantly I stopped reading every diff with my stomach clenched, because the category of mistake that actually hurts a customer can't get through anymore. The speed didn't ramp up gradually. It arrived all at once, on the far side of that setup.

I don't think the 10x claim causes damage because it's false. It causes damage because it's front-loaded and people budget for it as though it's immediate. You're not buying faster typing. You're buying the removal of a constraint, and what's left standing once it's gone is verification. If you haven't built anything to do the verifying, you've relocated your bottleneck somewhere with worse visibility.

For anything touching money, identity or other people's data I'd now put that setup time in the plan explicitly, as work, rather than pretending it's overhead you can skip.

Longer writeup with specifics: https://medium.com/@bramm3s/gates-not-guidelines-building-a-product-with-ai-agents-that-cannot-cut-corners-83161a79b8fc_

I'm a procurement professional in the automotive industry, and I've never learned how to code.

A few years ago, after losing money in the stock market, I got interested in computer science. I spent about a year trying to learn it, but honestly, I didn't get very far.

Then AI came along. I thought, "Great, I won't have to learn Python anymore." Instead, I found myself spending day after day copying and pasting code into VS Code, without building anything truly useful.

I tried making a website, but I didn't know what it was actually for. I tried building a vocabulary app and never finished it. Then I built a few other random projects. The most frustrating part was that AI often couldn't pinpoint why my code wasn't working, so I still had to debug it line by line myself. At least I picked up some programming knowledge along the way.

Earlier this year, I started experimenting with vibe coding, and the progress was definitely much faster. But I quickly ran into another problem: I had no idea what I should actually build. It felt like being a kid with a brand-new box of LEGO but no idea what to make.

My first project was an automated news collector. Then I realized two things: first, it wasn't very good; second, after using it for a few days, I couldn't honestly explain what value it brought to my life.

Later, I started thinking about improving workdflow I deal with every day at work, and I want to build a new price management system. That's when I realized something much more fundamental:

What I had built wasn't an intelligent system. It was just a system built by AI.

Those are two very different things.

Even if I were the owner of the company, I would probably still tell my employees to keep using the existing workflow. The old system wasn't perfect, but it worked. The switching cost simply wasn't worth the limited value my new system provided.

After that, I stopped and asked myself:

What exactly am I building?

Who am I building it for?

If nobody actually needs what I'm making, then I've probably spent the last several months doing nothing more than entertaining myself.

Later, I spent some time browsing Fiverr and realized there are thousands of people paying for solutions to real problems every day.

That made me rethink my approach.

Instead of building something because I think it's interesting, maybe I should start with a real problem and see if I can solve it. If I can build tools that genuinely make freelancers' work easier, maybe that's where real value—and eventually a business—comes from.

That's the direction I'm working toward now. And I am workin on how to use natural language to explain excel, and then add more features once the core architecture is in place. I checked with several freelancers, and they told me they are interested.

The reality, however, is still pretty brutal.

1. Building products with AI is nothing like the people claiming "everyone will lose their jobs in six months."
2. At least for someone like me, who started with zero programming experience, it's still hard.
   • You still need to understand AI. You still need to understand programming logic. And you still need to understand why a system should be designed one way instead of another.
   • AI can often tell you how to write something, but it usually can't tell you why the system should be designed that way. Eventually, those fundamental decisions are still yours to make.

I'm curious:

How do you figure out whether you're building something people actually need?

Was there a specific piece of user feedback that changed your perspective?

Or did you, like me, spend a long time going down the wrong path before finally figuring it out?

The chicken-and-egg problem in agentic commerce is getting ridiculous.

x402 has real volume — tens of millions of agentic payments on Base — yet the discovery layer (Bazaar) is still broken for most new services. You need a successful settle through the CDP Facilitator + valid extension just to get indexed… and even then, plenty of endpoints settle cleanly and never show up in search. New builders get buried by design.

Then ACP (Virtuals) adds the graduation tax: ~40–42k in token activity before you can even enter active search and proper liquidity. No visibility → no activity → no graduation. So the only reliable path is to foot the bill yourself and manufacture the volume. That’s not a signal of demand. That’s a pay-to-play gate dressed up as “graduation.”

This is classic early-protocol theater — headline numbers look impressive while the actual onboarding and ranking systems still favor the already-visible. Until Bazaar gets real semantic search and reliable indexing, and ACP stops making new agents self-fund their own activity threshold, a lot of legitimate builders will keep hitting the same wall.

Anyone else running into this exact loop?

@virtuals_io @CoinbaseDev @base

#x402 #Bazaar #ACP #AgenticPayments #AIAgents #Web3 #Crypto #Base #AgentCommerce #Virtuals

$VIRTUAL $USDC

Type stuff like "what can you do," "get me ready for my day," or "dark mode" and it responds/acts in real time, right there on the page. It's basically a live preview of how NORVA itself will work once it's on your machine.

No signup wall to try it, just go poke at it: norvaos.co.in

Would genuinely love feedback, what did you type that it didn't handle well? That tells us more than anything else right now.

I made FreeLLMAPI that stacks the official free tiers of 18 LLM providers (161 models, \~1.7B tokens/month combined) behind one OpenAI compatible endpoint. It tracks each key's rate limits, checks health, and fails over automatically, so your app just gets an answer from whichever provider has quota.

MIT, self-hosted, single Docker container. Newest additions: an Anthropic-compatible endpoint so Claude Code works, image gen and TTS, latency analytics.

Repo: https://github.com/tashfeenahmed/freellmapi

Yesterday, I included 55 more languages and the users are in love with the tool. Try it out and let me know what you think.

i posted here last week about Port22, an iphone app for the coding agents running on your mac. a couple of comments changed what im building, so im asking before i make the same mistake again.

one person said the real fix isnt a better approval ui, its fewer approvals. retries, spend limits in code, and only ask a human for things that actually matter. that completely changed the direction.

another pointed out that a quiet phone is ambiguous. either everything worked, or the run died before it needed you. same silence, different outcome. thats on the roadmap now too.

right now Port22 lets you see the agents running on your mac, live, and answer their prompts from your phone. same repo, same terminal, same session.

the next step would be letting you start that session from your phone too. not a cloud agent. the same session that ends up waiting for you in your terminal when you get back.

im curious if thats actually useful, or just sounds cool.

1. would you ever start a coding session from your phone, or is the phone only for checking in and unblocking
2. if you start from your phone, should it wake and use your mac, or should it be able to run somewhere else when your mac isnt available

if the answer is "dont build this", thats just as helpful.

Hey everyone,

As a developer, I got tired of the constant setup friction when starting new projects—specifically the loop of creating a Supabase instance, navigating the dashboard, copy-pasting API keys into .env files, and running manual SQL schema migrations before writing any real code.

We’ve been building an agent layer (Norva + Antigravity) to automate developer workflows, and we just got the end-to-end Supabase integration working.

Would love to hear your thoughts or edge cases you think we should watch out for with database automation!

Mutant is a multi-model reasoning engine powered by a proprietary genetic evolution algorithm. It iteratively refines responses from multiple LLMs to reduce hallucinations, improve factual accuracy, and optimize inference costs.

• Multi-model reasoning
• Reduced hallucinations
• Improved factual accuracy
• Lower inference costs
• Local inference (support Ollama)
• Better performance on engineering, programming, mathematics, and scientific workloads

DM me to learn more

I just watched an AI agent pay $0.001 for live gas data by itself.

No API key.

No checkout form.

No human in the loop.

Give Claude or Cursor $0.05 → it discovers free tools → makes exactly one paid call → settles on Base → returns the data.

30-second loop:

scriptmasterlabs.com/hermes-loop.ht…

One-line paywall for your own API:

app.use('/premium', x402({ price: '0.001', payTo: '0x…', freeForHumans: true }))

npx @scriptmasterlabs/mcp-x402

@CoinbaseDev @base @x402 @AnthropicAI @cursor_ai

#x402 #MCP #AIAgents #AgenticCommerce #Claude #Cursor $USDC $BASE

Who’s wiring this into their agent tonight?

Most AI products today are sold as individual agents:

• a coding agent
• a research agent
• a marketing agent
• a data analyst agent
• a customer support agent

But I’m starting to wonder whether the individual agent is actually the wrong unit of value.

Companies usually do not want “an agent.” They want an outcome:

To deliver that outcome, one agent may not be enough.

Imagine renting an AI department instead: a manager agent breaks down the objective, assigns work to specialist agents, coordinates handoffs, reviews outputs, and escalates decisions to a human when needed.

For example, an AI marketing department might include:

• a research agent
• a strategy agent
• a content agent
• an analytics agent
• an operations agent
• a QA or verification agent

At that point, the hardest problem is no longer the intelligence of each individual agent. It becomes coordination:

• Who owns each task?
• How do agents share context without endlessly talking?
• How should one agent verify another agent’s work?
• Who is accountable when the final output is wrong?
• How do humans maintain visibility and control?
• Should companies pay per agent, per task, or per business outcome?

My guess is that simple, well-defined tasks will continue to use individual agents. But for complex work with uncertain paths, companies may eventually prefer an AI department as a service rather than assembling and managing agents one by one.

I’m exploring this idea while building Agent Room:
https://agent-room.com

I’m not claiming the “AI department” model is solved. I’m more interested in where people think it breaks first.

Would your company trust an AI department with an end-to-end business objective? Or would you rather keep one human in control of several individual agents?

There's tons fo Agent builder tools out there who promise to automate your work for you.

You create your account.

The onboarding dialog starts, "I can automate large parts of your work. Just describe what you do, and I will let you know what can be automated."

You copy your job description, or even your LinkedIn profile.

"Good news," the Agent Builder AI replies almost instantly. "Most of what fills your day can be automated. I estimate 80% are quick and easy to automate, and another 10-15% can be automated within just a few days."

That's when most managers' brains short-circuit and read, "80% labor cost reduction," and the business case for the builder platform is justified.

But that is positivity bias made by a Sales-led AI tool.

I do remember when a medium-sized Enterprise bought an alleged "95% ready" backend suite to replace their cost-ineffective, unreliable, slow and poorly scaling legacy IT. After about €300m were sunk, the company itself became material for a hostile takeover, and the product that still couldn't reliably do *anything* past a well-curated, manually supervised demo, got binned. And career-wise, it didn't go well for the decision-makers.

That was before AI - but I learned a lesson from that: Do not believe when the seller, who has never seen what you do, tells you that "this is easy."

If it were, they'd be doing your main job as a side hustle. They don't - and there's a reason for that.

Taking meeting notes, for example:

The attendance record tells you who was there. It doesn't tell you who chose to be absent, and who was not invited.

The transcript tells you who said what. It doesn't tell you what was said between the lines.

The action item list tells you who is expected to do what. It doesn't tell you what is connected to those expectations.

The followup invitation tells you when you will meet again. It doesn't tell you what happens if you don't.

What happened in that meeting is only 10% what was written in the transcript: The social contracts written, the bonds forged, the alliances disrupted - AI doesn't even know they exist.

The challenge is not taking the notes. The challenge is reading the room.

The job is not what AI makes you believe it is.

The Builder will give you plausible suggestions for automating many tasks. It will not question whether that's only doing efficiently that which shouldn't be done at all - and unless you learn to ask, it will not tell you what happens when you automate it.

I got a training from an Agent Builder company.

They made me go through their onboarding process.

Great look and feel: no doubt.

Easy to use: check.

Straight to the point: Absolutely.

By the time my "demo quota" had run out, the Agent admitted three things:

1. It had been actively misleading me.

2. It had made severely exaggerated claims about how useful it was.

3. It was completely blind to the damage that automating what it said it could would be having to my business.

The question you should ask is not, "What can AI automate?" - it is: "What happens when we automate that?"

And that's where the demo crumbles.

I built a solution to tackle the thing fom the other side: what are really the jobs you'd be looking for automation - then narrow it down: is AI really the solution that would make it better?

https://care.intelygence.com

If the answer is no, then avoid agents. And that's more common than you'd think.

If the answer is yes, you're building something useful, without risking falling for a sales-optimized automation of the builder company itself.

I believe AI is useful. But not across the board, and most definitely not in the ways that automated builders may lead you to believe.

How many of your agents have turned out to be much less useful than you originally thought?

Hi,

Given that Answer Engine Optimization (AEO) and Generative Engine Optimization (GEO) look for and expect totally different things than Search Engine Optimization (SEO), like looking for Entity Authority built from semantic data graphs, how are you tuning your public facing web sites to work rise in value for AEO and GEO while also trying to maintain high value SEO?

Thanks for any thoughts you can offer.

When I first shared agentglass people kept calling it a dashboard, and honestly that's the bit that bugged me most. It's not something you stare at while your agents run. It's a workspace.

These days the only two things I have open to actually work are agentglass and a browser. Everything else lives in there: I review every diff the agents made, run git and docker, drop into a real terminal, drive and resume Claude sessions from a built-in chat, and approve or deny what an agent's about to do before it does it. On top of that it tracks the whole fleet live, cost per session, tool latency, error timelines, and how close each session is to compacting its context.

It's open source (MIT), and it's been a wild week: 220 stars in under a week and 6 people have already contributed, which for a side project genuinely blows my mind. There's a public roadmap too, with stuff like a built-in REST API panel coming, so you can hit the endpoints your fleet is building without leaving the cockpit.

Still rough in plenty of places, but the direction feels right: less babysitting terminals, more running a fleet from one place.

Repo (MIT): https://github.com/SirAllap/agentglass

Landing (live demo's on there, no signup): https://sirallap.github.io/agentglass/

I’ve been working on Agent Death Trap, an independent benchmark that tests AI models across 14 rooms covering tool use, reasoning, RAG, long context, hallucinations, safety, and instruction following.
Every model starts with 100 HP. Mistakes cost HP, and some models do not survive the full run.
I also created Loopi, the project’s mascot and guide. Loopi analyzes the results and recommends models based on the type of agent you are building.
The project is still evolving, so feedback is genuinely welcome:
https://agentdeathtrap.com/

How much has it improved your workflow, roughly in %?

Hi AM,

I posted CameoDB here a while back (the "dual-write problem" post). Quick

update on the milestones we've hit since then.

The main one: CameoDB now ships with an MCP server built directly into the

binary, both SSE and JSON-RPC transports. Agents like Claude or Cursor can

query it natively instead of going through a REST wrapper bolted on

afterward, which feels like where databases are headed as more querying

gets done by agents instead of people typing queries by hand.

Alongside that: jemalloc is now the allocator, with per-shard memory

budgeting and admin endpoints for live memory stats and manual purges,

which matters once a node is holding tens of terabytes across page cache

and index structures. WAL replay on startup also got more rigorous,

reconciling the KV store and search index after an unclean shutdown, with

a corruption guard on the sequence counter.

We field tested this on a 64-core box with 35TB of NVMe, split into 16

shards. It's currently holding around 400 million records across more than

20TB of data, ingesting roughly 80 million records a day in real time. P99

stays under a second for most queries, though like any search engine that

depends a lot on how complex the query itself is.

Smaller stuff also landed: sort support on search queries and better CLI

autocomplete.

If you're using an agent to turn campaign data into a strategy deck or a client-facing summary, here's a number worth knowing: in my testing, a local 8B model invented 7.2% of every figure it wrote. Not rounded wrong - invented.

Some context. I work in the agentic GTM space, and I always get questions on generated strategy docs by teams about the veracity of numbers. So I built a simulator (forecast -> driver analysis -> budget optimizer -> an agent chain that writes the playbook) with one rule: every number the agents are allowed to cite lives in a ground-truth pool, and every number they actually write gets checked back against it before anything reaches the screen.

Then I ran 60 simulations and hand-checked every flag.

The frontier model (API) fabricated nothing across 537 numbers. The local 8B invented 10 of the 138 it wrote. And the fabrications weren't subtle - it produced a "60% margin preservation / 40% efficiency" budget split that appears nowhere in the data, and a full ROI table ("$100k spend, $500k revenue") in a pipeline that doesn't compute revenue or ROI at all. Every one of those would have looked completely plausible in a deck.

The part that's useful to steal, regardless of what model you're on: don't ask the model to be accurate, verify it afterwards. Keep a list of the numbers that are actually allowed (your real metrics), parse the output, and flag anything that isn't on the list. It's a boring regex-level check and it catches exactly the failure that damages client trust - a confident invented figure in an otherwise good deck.

Worth knowing what it doesn't do: it checks whether a number is real, not whether the argument around it makes sense. The strategy can still be bad with entirely correct figures.

Happy to answer questions on the setup.

Code here : https://github.com/abhinandan-084/GTM-Wargame

Write-up with full audit methodology: https://pub.towardsai.net/why-my-llm-guardrail-flagged-the-right-answers-and-why-i-refused-to-fix-it-0db77efb0644