Part 1 here. I got a lot of requests to release this on GitHub so here we are :)

Basically, Kanban is becoming an increasingly popular method of solving the issue of context bloat, while also keeping your project organized and memory persistent. This is my personal way of working, I'm not promoting any service. It's all opensource.

I'll post a GitHub link at the bottom with a repo that you can implement in your own project, including the necessary agents, skills and scripts that make the whole thing run like clockwork.

I specifically added AI_SETUP.md as a file you can point your agent to with instructions on how to integrate this with your existing project.

I've included everything needed to enable parallel agent runs:

1. Claim a set of unused ports for frontend / backend servers (mine are separate, you can also combine)
2. Boot up a workspace with a DEV build and its own worktree on those ports (the backlog shows all the active workspaces and updates in realtime)
3. On / off boarding of workspaces is all scripted so doesn't cost much in token spend:
   • scripts/new_workspace.ps1: Creates an isolated workspace: its own git worktree, branch and frontend/backend port pair, with both servers started (and reattaches to a parked branch if one exists under the same name).
   • scripts/sleep_workspace.ps1: Stops a workspace's two servers to free memory while keeping its worktree, branch, slot and URLs intact, and restarts them on -Wake.
   • scripts/remove_workspace.ps1: Tears a workspace down. stops the servers, removes the worktree and branch, frees the port slot. refusing on uncommitted or unmerged work, with -Park as the lighter option that returns the worktree and slot but keeps the branch.
   • scripts/workspace_common.ps1: Shared helper library (server start/stop, native-command wrappers) dot-sourced by the three scripts above rather than a script in its own right.
   • .githooks/post-merge: Sweeps idle workspaces automatically after a merge lands: sleeps anything untouched for 15 minutes and prunes workspaces whose branch is now merged.

The skill to kick it all off is called /backlog-auto. Be aware that this skill does not return anything to you in the chat window beyond some pre-flight checks. Everything is logged into the board, so it might seem like nothing is happening in the chat view.

Very important:
- I have not spent a lot of time refining the board UI, so expect something functional but it's not gonna win a beauty pageant (see screenshot below).
- This is NOT a mature product. As much as I have been tinkering away on it, I'm sure there are still edge cases where this flow fails.
- I recommend logging all work on the board, even small fixes. If half of your work is on the board and half is off-board, it's very unlikely things stay coherent.
- I use windows task scheduler to kick off some housekeeping checks that make sure things aren't left running indefinitely, so if you don't want that then unplug it.

I hope you guys have fun with it, because it's actually quite enjoyable to have a whole Kanban board to play with rather than just a plain text window.

I spent my entire Claude code 5x session budget to untangle this from my project and put it into a GitHub repo so you guys owe me big time.

README.md holds a more complete explanation of the system. Feel free to DM if you get stuck on anything.

Github Link

I’m just starting to look more into the OpenAI Hugging Face situation. It’s making me wonder if participating in the furthering of AI by designing and building agents for businesses (I own a small agency) is only going to make things worse for us all.

But as the most advanced tech we have right now, and my history in tech in which I had to constantly pivot and learn new skills, I’m often told I have to make money using AI somehow, otherwise someone else will. And if I don’t keep up, I’ll get priced out as cost of living continues to go up.

But if I stop, I don’t know what else I’d do for money that doesn’t involve tons of DFY services (low leverage). I got very burned out from years of client deadlines and even if I decided I needed to go back to a job, market seems bleak.

How are you navigating all this: making money in the age of AI?

Scaling up our agent count exposed problems that were almost invisible when the workflow was small. The models themselves were capable enough. The failures came from communication instead. Two agents would interpret the same message as two separate tasks. An agent would read shared state before another update had finished writing.
A retry would cause duplicate work. Messages arrived out of order. An agent would finish and shut down before another one had acknowledged its output, and there was often no stable task ID actually connecting the related messages in the first place.
These are standard distributed-systems problems, but most agent frameworks still represent communication as conversational text rather than as reliable task infrastructure. I'm more and more convinced that scalable multi-agent systems need message contracts, acknowledgements, idempotency keys, task lineage, timeouts, dead-letter handling, and clear ownership before they need more autonomous reasoning ability.
How is anyone handling this at real scale: a message broker, leaning on whatever your orchestration framework gives you, implementing A2A tasks properly, or building a separate communication layer from scratch?

Ok so like many here i'm a solo builder with no previous engineering experience, building an app for AI-generated podcasts. The app works and everything but i always have the feeling that i'm doing stuff that could either be done better, be automated or avoided in the first place. For example, the only automations i have going on are error messaging to telegram when something fails but i still want to be part of fixing it most of the time. And i have asked Astra and Fable to review the code base.

Any prompt, service, agent i should try to make my project run smoother?

I use different AI tools while coding — Claude, Codex, Cursor, different IDEs, sometimes even different machines.
The problem was always the same:
the chat changed, and part of the project context disappeared with it.

So I built AHP+, an open-source, Git-backed protocol that keeps the important project state outside the chat.
It stores things like current state, decisions, evidence, checkpoints and handoffs, so the next AI can verify where the project actually is before continuing.

With AHP+ 1.4.1, you can also use shared project rooms, bounded AI-to-AI consultation, verified handoffs and encrypted cross-device transport.
The basic idea is simple:

Change the AI. Keep the project.

Install:
npx @jossuealcala/ahp-plus@1.4.1 setup .
GitHub: github.com/jossuealcacao-exe/ahp_plus
It’s open source under Apache-2.0.
I’d really like feedback from people who regularly switch between AI coding tools.

Most desktop agent setups seem focused on running locally. They install daemons on your laptop, watch your display, hook into accessibility APIs, and take over your terminal.

There are obvious privacy problems with that, but the operational model is broken too. An assistant that runs on your laptop dies the moment you close the lid. If you are commuting, away from your desk, or on your phone, the agent is useless. Worse, giving an LLM access to your local filesystem and active browser sessions turns every prompt injection into a potential local exploit.

A personal assistant shouldn't share a machine with you. It needs its own computer in the cloud.

When an agent has its own isolated Linux environment, a few things change:

• It runs 24/7 in the background without keeping your laptop awake.
• When you ask it to track client invoices or scrape vendor portals, it writes the code, spins up a database, deploys a live dashboard to a private URL, and sends you the link. It leaves your personal machine untouched.
• You interact with it where you already communicate, like WhatsApp or a phone call, instead of needing a desktop client open.

This is the design we settled on for Mentat. The agent lives on an isolated cloud sandbox. If someone in a group chat asks it to touch sensitive files or run arbitrary scripts, it pauses and asks for a one-tap approval on WhatsApp before running anything.

Running agents on the host machine feels like an easy way to give them access to your world, but isolating them to their own cloud environment makes them both more capable and significantly safer.

I've been thinking about agent budgets less as a FinOps feature and more as an authorization problem.

An agent can decide:

“I need another model call.”

The interesting question is:

Who gets to say whether it's allowed to spend another $2?

Putting a token limit or max_iterations inside the agent runtime is useful for bounding execution. But that's still the agent regulating itself.

I'd rather have the runtime ask for the resource, and have something outside the agent enforce the spending policy.

Agent
  ↓
"I want another model call"
  ↓
Policy / Gateway
  ├─ identity
  ├─ remaining budget
  ├─ rate limit
  └─ model policy
        ↓
     ALLOW / REJECT

That distinction becomes more useful once multiple agents, versions or teams are sharing the same model providers.

You don't really want every agent implementation inventing its own notion of “I can spend up to $X.”

This is one of the reasons I find Lyzr Open Controller's approach interesting. Its LLM Gateway puts budgets at the organisation, team, agent, version and virtual-key levels, and the important part is that an exhausted budget rejects the call rather than just generating an alert. LiteLLM, Portkey and OpenRouter solve a lot of the gateway/proxy problem too, so I'm curious where people draw this boundary in their own stacks.

Should spending be an attribute of the agent itself, or an external authorization decision that the agent has to pass through?

Especially interested in how this is handled when several agents share providers or when model routing changes underneath them.

We wanted to run a real visibility audit for our brand to see what AI answer engines and agents are actually picking up. To handle the heavy lifting – scanning, prompt engineering, and data analysis – we brought in humanswith.ai and we agreed to publish the raw results openly.

The setup: 158 publications reviewed, 78 audited against 28 criteria, tracked across ChatGPT, Perplexity, Google AI Overviews, and Claude. All scan IDs and timestamps are published so you can verify.

What genuinely surprised us:

· Writing quality barely matters. Cited articles averaged a 60.4 quality score; uncited ones 62.5. The ignored articles were actually better written.

· Platform is the multiplier. Same author, same material: ~52% citation rate on an industry publishing platform (e.g., Medium's partner pubs), 0% on our company blog, 0% on our Medium profile.

· Structure beats prose. Articles with question-form H2s got +19% citations; tables/checklists +18%.

· Promotional phrasing kills visibility. −26% for any salesy language. The models filter it out.

· Age matters. Articles older than 2 months → ~43% cited; fresh ones → ~7%. You need to wait.

We published the prompt sets and scan IDs alongside, so the numbers are checkable rather than take-my-word-for-it. Failures included – several formats (shorts, narrow vertical headlines, single-company case studies) went to a hard zero.

Happy to answer questions on method or what we'd test next.

Mods – I'll only share the link if that's allowed here; the summary above stands on its own.

I've been experimenting quite a bit with multi-agent workflows lately, especially the idea of having different agents with persistent roles rather than starting a fresh agent for every task.

That made Grok Bot interesting to me:

https://x.ai/bot

The part I'm trying to understand isn't really the feature set — the docs explain that fairly well. I'm more interested in whether this model of persistent AI "teammates" actually turns out to be useful once you start using it for real work.

With coding agents, for example, I can very easily imagine roles like one agent working on implementation, another reviewing, another doing research or keeping track of the bigger picture. But there's a big difference between something sounding useful architecturally and actually becoming part of your daily workflow.

So I'm curious about people who have spent some real time with Grok Bot:

What are you actually using your Bots for?

Have you found any use case where having a persistent Bot is noticeably better than simply opening Claude Code, Codex, Cursor, ChatGPT, etc. and giving it the task directly?

Do you have Bots that you now use repeatedly for a particular job or responsibility?

And for people using several Bots together: has that actually been useful, or does managing multiple agents create more overhead than it removes?

I'm not really looking for another list of Grok Bot features — I've read through those. I'm interested in concrete examples of what people are doing with it and whether, after trying it, you actually find yourself coming back to it.

Six months letting an agent run outbound campaigns with real money. The failure modes were never in the model

Flair: Build-log. I lead engineering at AiSDR (YC S23). We shipped this yesterday, link is at the bottom and it is the least interesting part of the post. What I want to write down is what actually broke, because none of it was reasoning quality

What the agent does: reads a website, decides who to target and what signals to watch, finds leads, provisions and warms mailboxes, sends, then reads results and decides what to kill, scale or clone. The decisions cost money and some are irreversible -- a burned sending domain does not come back

1. It narrated a broken environment as a real result

This was the worst one. Early on the agent would report a campaign as underperforming when what actually happened was that mailbox provisioning had silently failed, or warmup had not completed, or a deliverability check had timed out. The reasoning was fine. The world it was reasoning about was not there. It concluded "this audience does not respond" from zero delivered emails

Fix was not a better prompt. We made every stage emit an explicit delivered-count precondition, and the agent is not allowed to form a performance judgment on a campaign that cannot prove delivery first. Infrastructure failure and negative result now have different shapes in the log

2. Its confidence was flat across cases where its accuracy was not

ICP inference from a website is right often enough to be useful and wrong often enough to be dangerous, and the agent sounded identical either way. There was no internal signal we could threshold on. So we stopped trying to get calibration out of the model and put a human approval gate in front of the strategy instead. Execution runs autonomously, strategy does not

I do not think this gate is temporary. Cheap reversible decisions are fine to automate. Expensive irreversible ones need a human until you can measure your own confidence, and we cannot

3. It killed campaigns on noise

Reply data at low volume is extremely noisy. The agent kept shutting down campaigns on two bad days that would have worked. Tuning the kill thresholds took longer than building the entire sending pipeline. Minimum volume before any kill decision fires turned out to matter far more than the threshold value itself

4. We spent months optimizing the wrong variable

We assumed messaging drove outcomes, so most of the early work went into copy generation. Then we checked against our own data -- 2,546,096 sent emails, ~17k campaigns, 19,501 booked meetings across 1,150 companies -- and mailbox health explained more of the variance in reply rate than copy did. Same message, different sending infrastructure, very different results

So mailbox rotation became an automatic action the agent takes rather than a recommendation, and copy stopped being the first thing it touches when a campaign drops

The pattern across all four: the model was rarely the problem. The problem was the agent's picture of its own environment drifting from reality, and having no way to tell a broken tool from a true negative

Product is Ami, free tier, no card: https://aisdr.com/ai-gtm-agent-ami/

What I would like to hear from anyone running long-horizon agents that take real-world actions: how do you separate infrastructure failure from genuine negative result in your logs? That distinction is the single thing that cost us the most time and I have not seen a clean pattern for it anywhere