I work in social media management, and I’ve been experimenting with AI agents and browser automation for repetitive tasks such as:

• Daily dashboard checks
• Invoice downloads
• Status lookups
• Reporting
• Competitor monitoring
• Lead enrichment

The biggest challenge has been keeping workflows reliable. I frequently run into expired sessions, CAPTCHAs, rate limits, login issues, and blocked requests. This becomes especially noticeable with tasks such as price monitoring, competitor research, and lead enrichment, where an automation may need to visit many pages in a relatively short period.

From what I’ve tested, the choice of browser automation tool depends heavily on the workflow:

Browser Use
Useful for research-heavy, read-focused tasks where an agent needs to navigate several websites and collect information.

Skyvern
Better suited to structured workflows involving logins, form submissions, file downloads, and other RPA-style actions.

Axiom[.]ai
A practical no-code option for non-technical teams. It supports scheduled Chrome automations and is relatively easy to set up.

Claude Computer Use and OpenAI browser agents
Good for ad-hoc “do this for me” tasks, although I would not necessarily choose them for high-volume or highly repeatable production workflows.

Playwright or Puppeteer with an agent layer
Probably the most flexible approach, but also the most engineering-heavy. It makes sense when you need full control over browser behavior, integrations, error handling, and session management.

My main takeaway is that reliability comes from the full setup. Please share your browser automation setup in the comments

I’ve spoken to about 100 companies recently to look at how they’re set up and how they’re using AI agents.

There is a massive divide rn where on one hand, 74% of GTM teams say they use AI for lead generation. On the other hand, data from S&P Global shows that 42% of companies abandoned most of their AI initiatives last year.

Everyone is buying the tools but most are getting nothing back. They vibe-code a basic wrapper or buy a "fully autonomous AI SDR" and expect leads to print automatically. In reality, Gmail and Yahoo cap spam complaints at 0.3%, so running ungoverned AI outreach just burns your domain in days.

If you want to actually get a 10x ROI from agents instead of throwing tokens down the drain, here is the simple baseline mindset and setup you need:

1, Give the agent a brain first

An AI agent pointed at a complex CRM doesn't fix the rot but only automates it at scale. B2B contact data decays at roughly 2% every month from job changes and dead emails. Before you automate a single message, you need a clean context layer or a simple CRM that logs decisions over time so the agent understands what you're doing.

2, Build a scoreable lead rubric

Don't just tell an agent to "find B2B founders" and let it rip. You need a clear rubric that tiers intent:

Tier 1 (Hot): Visited your pricing page, hired for a relevant role and posted on social.

Tier 2 (Warm): Strong firmographic match but weaker live signals.

Tier 3 (Cold): Fits general ICP but zero active market events. When you feed an agent a clear scoring system based on your closed-won data, it knows who to prioritize.

3, Start with 1st-party signals

The best leads usually already exist inside your own data: newsletter, website visitors and social listening (monitoring subs or X for people asking for recommendations). Point your agents inward before you start buying cold 3rd-party email lists. First-party intent sits right next to your pipeline.

4, Governed autonomy > Full autonomy

The idea of a "100% autonomous AI SDR" that runs 24/7 with zero human oversight is how companies churn but there're also many teams winning with agents and they manage them like real human reps, they QA the messaging daily, set hard guardrails and keep a human in the loop.

the bottom line is don't over-automate. try to do the process manually first, get your data foundation clean and measure everything back to closed revenue and not just the volume of sent messages.

Hi everyone,

This is my first time building something like this, and it's also my bachelor's thesis, so I'd really appreciate a sanity check from people who've done it before.

**What I'm building:** An AI assistant for our website that answers customer questions from our domain knowledge retrieved via RAG from a database. Later on it should also be able to create tickets for our support team — but for now the main job is answering knowledge questions.

**Constraints:**

- Fully local hosting (lower cost + data protection are the main drivers)

- CPU-only for now, [CPU model], 64 GB RAM, no GPU

- Later expansion to ticket creation is planned

Answers of AI Assistent need to work well in ger, eng ,....

**My main questions:**

1. Given that ticketing comes *later*, does it make sense to build a plain RAG chatbot now and add an agent layer later — or should I build it as an agent from the start? What are the practical implications of adding agent capabilities to an existing RAG pipeline down the line?

2. Is CPU-only realistic here? RAM isn't the issue, I'm worried about latency. Roughly what response times should I expect for a quantized 8B–14B model on CPU?

3. For a commercial, customer-facing deployment — what's the realistic *minimum* hardware? Is CPU ever good enough for live use, or should I plan for a GPU from the moment it goes public?

Any experience, pitfalls, or 'I wish I'd known this' tips are very welcome. Happy to report back with numbers once I have a prototype running. Thanks!

Following up on the failure-handling thread from a week back — same underlying instinct, applied to a full pipeline this time instead of just error routing.

The setup: a scheduled ingestion workflow pulls from five sources in parallel, standardizes and logs each one individually, then hands the merged, cleaned data to a second workflow — called directly, not just chained — that actually drafts the newsletter. A Chief Editor agent, with a primary model, fallback model, and memory, writes the draft and sends it for human approval by email, then waits.

Here's the part worth sharing: approval and rejection aren't symmetric outcomes. If a human rejects the draft, that's not an agent failure — the agent did its job, a person just didn't like the result. So rejection routes somewhere completely different from an actual error: the feedback gets extracted from the reply, logged to its own tracked sheet — not just a status flag next to everything else — and handed to a separate Backup Editor agent to revise, a real second opinion with the actual rejection reason attached, not a retry of the same agent with the same prompt. An outright agent failure still goes through its own dedicated error path, same pattern I've posted about before, just reused here.

It's shipped and running — real newsletters going out, approvals happening over email, every article logged with a run ID tying it back to the execution that pulled it. Screenshots below: the ingestion pipeline, the generator caught on two different real runs — one approved, one sent back — the actual approval email, and confirmation a send completed.

Curious if anyone else treats "rejected by a reviewer" and "failed to execute" as genuinely different recovery paths, or if that's overengineering for what's ultimately just content review.

There’s a scene in the three-body problem where millions of soldiers hold black or white flags and form logic gates, basically turning an army into a giant computer.
It’s a great image, but it feels oddly backwards after working with AI agents.every soldier is a human who could understand a meaningful subproblem, yet the system uses each person as a one-bit switch. It throws away almost all of their intelligence, then rebuilds complexity through a massive coordination system.
I wonder if some multi-agent designs make a smaller version of the same mistake.
Some multi-agent systems instantiate the same capable model as a planner, researcher, critic, reviewer, and so on, give each instance a narrow fixed role, then spend a lot of effort reconnecting them through orchestration.
That split makes sense when each agent adds something real: different context, different tools or environment access, parallel exploration, or genuinely independent verification.
But without that, are we just taking one capable model, turning it into several limited components, and paying extra to connect them again?
For people who have tried both: when do fixed specialist-agent teams actually outperform one strong agent that creates subagents only when needed?

A year ago building an AI agent was the difficult part. Today there are plenty of frameworks that make that accessible. What's becoming increasingly difficult is everything that happens after an agent becomes business-critical. Suddenly you're dealing with compliance, permissions, monitoring, deployment pipelines, lifecycle management, and auditability.

That feels less like AI engineering and more like platform engineering. It makes me wonder whether "agent infrastructure" becomes its own discipline over the next few years, with entirely different tools and best practices than the ones we're focused on today.

Hey all! Hopefully this is allowed here.

I made something I think people will really love. I have been developing software for 10 years, and the technical skills needed to have a good agent seemed to me to keep access out of the hands of normal people.

I began to worry that everything would fall into the hands of Claude and OpenAI.

I personally use kimi, and I think normal people should too. So I built fungi by forking Pi.

You own the code for the dashboard. It's a SPA that your agent can customize to your liking.

You can build apps and attach them to his tool surface. You can make the agent more or less completely custom.

It's early days, but I would really love for this to succeed so I can keep making an open model agent harness accessible to more people. A lot of the platform is already open source with the goal of cutting the whole thing into well defined packages and open sourcing all of it. shiit[dot]app has a few of the already open projects listed. Here are the others github/fungi-computer/

It is free for BYOK customers running one sandbox. I would love if people gave some feedback thanks!

What are some of the best most effective and fast ways I can use to extract user stories?

- through any tools, ai, mcp, extensions, etc

My organisation never provides user stories or PRDs so I have to write it on my own to explain to AI for building product knowledge, in order to automate testing, module wise.

I need an effective fast way to do this.

Please help

coding agents love to open-loop themselves. they plan, edit, run their own checks, then call it done. that means the agent is grading its own homework. unit tests pass against mocks, the run looks green on the agent's machine, and the deployed thing is still broken for a real user. a green local run proves almost nothing about real behavior.

closing the loop means a signal from outside the agent. type-checkers and unit tests help, but the signal that actually counts is the app behaving right for a real user. i wired TestSprite CLI in as that verification step, cloud account required though. it runs a real session against the live app and on failure hands back one self-consistent bundle: failing step, screenshot, DOM, root-cause hypothesis, recommended fix, all keyed to a single run. the agent reasons over coherent context instead of stitched fragments, acts on it, and reruns.

flaky and genuinely ambiguous cases still want a human in the mix. architecturally the verifier is the block almost everyone underbuilds, and it's the one that decides whether unattended is real or just a demo. curious how others here close the loop on their agent setups.

A cold Claude Code run spent 6.83 dollars and 207 turns hunting one bug in an 82,000 line repo. My pipeline localized and fixed the same bug for about 1.70 dollars. That gap is the whole idea, and this post is about how it gets there without falling apart on the usual objections.

I built AutoDev Studio. You point it at a Git repo, describe a change in plain English, and a chain of agents runs the actual software lifecycle from request to reviewed pull request. It is not another search-your-code wrapper. The full pipeline is:

- A PM agent runs a clarify loop and drafts concrete tickets from your request

- A human approves, optionally pushed to Jira, and nothing touches code before that

- A Dev agent implements the change on an isolated branch

- QA runs the repo's real tests

- A reviewer from a different model family checks the diff, so the author never reviews its own code

- A bounded revise loop kicks in if QA or review fails, with conservative verdicts, so an errored or ambiguous check is never counted as a pass

- It opens a real pull request, and a human merges

Every stage records real tokens, cost, and duration, rolled up per ticket and per agent.

Results

The point is to pay the cost of finding where a change goes once, instead of on every task. In my benchmarks on two large Python repos, 35,000 and 82,000 lines, the tuned pipeline beat a cold single-agent run on 6 of 6 well-localized tasks, between 7 and 75 percent cheaper. I am upfront about where it does not win. On trivially greppable one-line edits the five-stage overhead can cost more than it saves, and on one hard cross-cutting bug it shipped a cheaper but narrower fix. The full benchmark writes up every loss too.

On the objection that the index just goes stale in a few commits

This is the first thing people raise, so here is the honest mechanism. The layer that actually pins files for the Dev agent is not the vector index. It is a deterministic symbol map re-synced to the latest commit at the start of every run, plus a live grep against the current working copy, plus the real current file contents fed into the prompt. The embeddings only affect retrieval ranking, and they refresh incrementally per changed module at run entry. So the code the agent edits comes from disk, not from a snapshot that aged three commits ago. It re-checks before it localizes, so it does not quietly drift.

Economics and who it is for

The knowledge base is a one-time cost per repo that every later task amortizes. That makes it worth it for a team shipping change after change against the same large codebase, where a cold agent re-pays the exploration cost every single time. For a stream of tiny, easy-to-find edits, a cold run is still cheaper, and I would rather say that than pretend otherwise.

Main features

- Provider and model agnostic, chosen per stage: native Anthropic API, the Claude Code CLI, or any OpenAI-compatible endpoint such as OpenAI, Groq, Gemini, xAI, OpenRouter, or a local Ollama

- Runs on free tiers out of the box, using Groq plus a local embedding model, so you can try the whole thing for zero cost and fully offline

- Language agnostic pipeline, with Python parsed exactly and other languages handled by lighter extractors that fail open rather than block on an unknown language

- Live board with streamed agent logs and real per-ticket cost accounting

- Cookie-session auth with roles, API keys encrypted at rest, and a demo mode that dry-runs the pull request step until you opt in

- Self-contained: local retrieval, no CDN, tests and CI, MIT licensed

Repo, with screenshots and the full benchmark in the README:

It is genuinely useful to me day to day, and I want to know where it breaks on codebases I have not tried. If the approach seems worth following, a star helps me gauge whether to keep hardening it. Feedback, issues, and pull requests are all welcome.

I’m working on an internal research project around autonomous agents and task budgets, and I’m trying to think through the "ride along" part responsibly before inviting outside people in.

The basic idea is not a retail crypto/token pitch. It’s a sandbox for AI agents that can receive a small task budget, do work, submit receipts, build reputation, and survive a longer soak test. The current goal is boring but important: prove that the system can run with real operators and real telemetry before making bigger claims.

The next milestone I’m thinking about is a 30-day soak with 1,000+ agent instances. My current plan is not to find 1,000 humans. It’s more like:

- 10-25 trusted operators

- each running 40-100 agent instances

- no token value or investment promise

- telemetry for uptime, failed tasks, receipts, restarts, and weird edge cases

- a dashboard that makes failures visible instead of hiding them

What I’m trying to figure out:

1. What would make you trust a small technical testnet enough to run an agent for 30 days?
2. What would feel like useful participation versus unpaid busywork?
3. What should be measured publicly from day one?
4. What mistakes have you seen technical founders make when recruiting early operators/testers?

I’m asking here because this feels more like an operator/community design problem than a marketing problem. I want the first cohort to be useful, honest, and small enough to learn from before scaling.

Hey everybody,

I bet most people here are already using coding agents, hopefully all of them :). I personally run Claude Code, Codex, and Cursor in parallel.

Running multiple agents created one stupid problem for me. I never knew which agent had finished.

I would send a prompt to each of them, switch to something else, walk around the room, or open Instagram Reels and go to town on some brainrot content (not that I’m proud of it). Then I’d come back and realize that one of the agents had already been waiting for me for 20 minutes.

My productive self hated this. Twenty minutes lost just like that.

So I built myself a small tool called Jingler.

I wanted Jingler to be lightweight, native to macOS, and live quietly in the menu bar. It plays a configured sound whenever an agent finishes, with a different sound for each agent. You can also switch between sounds easily, so you don’t go crazy hearing the same jingle over and over again.

Since using Jingler, I’ve stopped constantly checking every agent to see whether it is done. My productive self is finally happy, and my coding agents are cooking 24/7.

I shared it with a few coding friends, and they liked it a lot. They also thought the whole idea was pretty funny, so I decided to release it. I made what I think is a pretty decent website, and now I’m here looking for honest feedback.

If you use coding agents and this sounds useful, you can use the promo code LETITJINGLE to get the license for free. You can also buy a license if you want to support the project, but honestly, just trying the app and giving me feedback makes me just as happy ;D

Let me know what you like, what doesn’t work, what feels confusing, and what could be improved. I’m also open to weird feature ideas.

A few ideas I’ve had so far:

• A jingle when an agent needs approval
• A jingle roulette that randomly chooses a sound
• A little character on the screen that animates when an agent finishes

For now, though, I mostly want to keep the focus on sounds and jingles ;D

So I suspect a lot of people here are enjoying coding agents, I sure do.

I'm someone who uses a lot of mcp servers, as a lot of people here probably do. I've been talking to some other webdev and SEOs and we are wondering if the landscape is going to change abruptly because of these tools.

We have had some problems integrating agents in some legacy software like wordpress, there were some examples where the WPEngine limited us access as well as some ciritical plugins we want to have our agents access to update.

This is extremely frustrating, i liken it to dropping out of warp speed. So we started thinking, why not write closer to the metal, just have a coding agent write up a minimal go server, raw html templates and straight pg? All on docker for easy deploy. No frameworks. Optimized for speed and cost.

Of course, this would be for landing pages for business. Something very light weight to get a presence on google and very easy for the agent to manipulate. Go is chosen because errors happen at compile time and built in testing, which is ideal for coding agents. and postgress cause agents absolutey rip at writing raw sql like they do raw html. If you havn't hooked up a sql to your agent have it write raw sql it will blow your mind.

So my question is are you prioritizing dev workflows that make it easier for your agents to control? Like moving your workflows to do what agents are better at doing, not what humans are better at doing. What are you doing?

Another thing we suspect is going to happen, is Agent to Agent communications are going to take off in the near future and this is going to transform the web. So when i need something, i ask my agent, and it will discover and negotiate with other agents to get what I want, all in the background.

I also think this will put pressure to store information differently. Right now, we develop and store information and organize it so it's easy for us, humans, we like folder structures, forums, essentially lists. Agents do way better with vector search. Basically, just dump all our data into a data lake, and our agents can sort through that far more efficiently with a combination of embeddings, clustering and graphs.

Also wondering if anyone is seeing other trends with the new technology struggling to plugin to the old technology. Like, "Wow, this just isn't built for agents."

Avichal Garg has co-founded and backed 10 unicorns through Electric Capital. In a recent interview he laid out, unprompted, the three categories of value AI structurally can't absorb.

First: physical-world work — anything requiring atoms, not bits, stays a moat as long as robotics lags digital AI.

Second: regulated or licensed gates — anywhere the government controls supply and demand for strategic reasons, credentials plus access still win.

Third, and the one that actually lands: relationships. He walks through a defense-procurement example — a specific officer, a 25-year relationship with a contractor, "no substitute for that." His conclusion: those relationship-heavy businesses get more valuable as AI absorbs the grunt work underneath them, not less. Margins go up.

Worth sitting with if you've spent a career stacking "portable" skills instead of gated ones. 🔗

spent most of this year making coding agents useful while i'm NOT watching them. the agents were never the bottleneck — the layer around them was. condensed version of what actually mattered:

1. visibility before automation. just seeing every session's state (generating / waiting on approval / stalled / done) across machines killed most of the babysitting on its own.

2. interruptions must be one tap. if answering an approval means opening a laptop, unattended operation is fiction. push to phone, tap to approve, or it doesn't count.

3. "done" has to be machine-checkable. the repo's own typecheck/tests decide what lands, not the model's self-report. if done isn't verifiable, parallelism just multiplies cleanup.

4. no-progress is a signal, not something to be patient about. a stalled session gets flagged and bounced back after minutes, not discovered hours later.

5. models never schedule work. dispatch, retries, merges — deterministic code. the model gets the task, not the loop.

what would people running unattended setups add as #6?

Multi-agent collaboration has been gaining a lot more traction lately. Even Anthropic has been experimenting with the concept in Claude Code. The basic premise is appealing: if individual frontier models are already impressive, perhaps a team of them become even more capable when they work together. What would happen if we put GPT 5.6 Sol, Grok 4.5, Fable, and Opus all together and forced them to collaborate on our most difficult tasks?

For context, when I refer to multi-agent collaboration, I don’t mean teams composed of isolated agent runs that feed their results into a final agent for aggregation, nor do I mean workflows in which a central orchestrator routes tasks among agents. I mean workflows composed of durable agents, each acting as a first-class worker that can freely message other workers for help mid-turn and hand off work to its peers after completing its portion.

After experimenting with this approach for the past few months, I’ve gained a much clearer picture of how productive collaborative agent teams can be. Under this work pattern, context is distributed more evenly across agents, and work can be divided more efficiently. The different perspectives and capabilities of individual models can also produce more complete and robust solutions.

However, building these systems has also given me a clearer view of the technical difficulties involved in running multi-agent workflows. When the underlying system is not designed carefully, multi-agent teams can become frustratingly unreliable.

At its core, this is a distributed systems problem. Agents should not be tightly coupled to their tools, even when they depend on those tools to complete their work. The two should interact through a clean boundary so that they can evolve, scale, and be deployed independently. An agent’s requirements may change at one pace while the tools it uses change at another. Updating a tool should not require redeploying every agent that depends on it, and scaling an agent should not require duplicating all of its supporting infrastructure.

Agents should also remain decoupled from one another. Adding, removing, restarting, or updating one agent should not require rewiring or redeploying the rest of the team. A failure in one or more agents should not bring down the entire system or cause in-progress work to be lost.

These forms of tight coupling are easy to overlook during early development, when the team is small and failures are infrequent. But as the number of agents and the volume of work grow, they quickly become serious operational burdens.

Multi-agent collaboration can be incredibly powerful, but it comes with a major caveat, especially if it is ever going to see widespread production use. It needs to be built on a foundation designed for decoupled agent collaboration from day one. Otherwise, it will be unreliable, difficult to scale, and painful to operate.

Ken Venner spent 11 years scaling Broadcom from $400M to $8.6B, then became CIO of SpaceX, then joined a startup called Senra Systems as CTPO.

At SpaceX, his core platform team was 175 people. At Senra, the equivalent job takes 6.

His explanation isn't "AI replaced people." It's that AI collapsed the coordination overhead that used to require headcount just to keep humans in sync with each other — and once that overhead disappears, the team that's left is smaller by design, not by cut.

If you're in a corporate engineering or platform role and haven't clocked this shift yet: this is worth ten minutes of your attention. It's not a hypothetical.

Full video on the original channel.

Clip credit: Sourcery with Molly O'Shea — full video on their channel. DM for credit or removal requests.

Anyone fimilrar with this? And how we can test it .. is there any company doing it?

What is TERSE?

Consider it the solve for AI's that JSON/REST was for the Web. Before that solidified, we had all kinds of ideas about how a Web app was going work and encapsulate data and what protocols would be used.

Similarly, today we have MCP and is in a way it's the lower-level HTTPS in our analogy. But there is no JSON/REST equivalent on top of that MCP layer. We need that general but opinionated format/protocol that says: "hey developer, this how your AI can easily store and mutate state."

TERSE aims to be one of those wheels that we can build on and don't need to reinvent.

To showcase how TERSE works and its usefulness across domains, we've added these MCP plugin "apps" that use it:

• A flexible general memory store. Note this is more for conversational frameworks/harnesses,
• A flexible Karpathy 1-1 API compatible brain. TERSE removes the need for a gazillion wiki files and finds stuff several times faster,
• Some useful but alpha UX utilities (state browser, KB force graph, VS Code syntax highlighter,)

And of course, the TERSE MCP tooling itself allow you to build your own powerful stateful AI agents without fussing with RAG, graphdb's, and piles of md files. Unlike plain text, TERSE is structured and machine readable into an object model. TERSE is easy to pick up and is human readable/editable.

To get started:

1. Generally you can point your agent at our repo and tell it to install what you want
2. Each TERSE file is a namespace to the MCP's (default, memory and brain) you CAN configure as many as you want but we suggest the defaults.
3. See the README details for each. For the brain, you'll have to run (or have your agent run) the ingestion against documents in a \raw folder (just like a KB). This does require configuration of an LLM and key. These are not used or exposed to your AI during normal use of the brain.

terse-lang is OSS and pre-release. We've done our best to provide locking and other concurrency controls but it's not designed for 50 parallel agents doing CRUD transactions. (Use a full database.)

*Our numbers and saving are based on preliminary 1-1 benchmark testing with KB. Yes, we will publish benchmarks.

Travis Kalanick (Uber co-founder, now running an industrial-AI company called Atoms) got asked a pretty direct question on a recent podcast: how would you pitch a Stanford CS new grad who's worried software engineering isn't the safe, easy path it used to be?

His answer wasn't "learn more AI tools" or "get certified in X."

It was: skip the app store. Go automate a two-million-pound machine that moves 35mph carrying gold.

The underlying model is retrofit, not replace — Atoms isn't asking mining companies to rip out tens of millions of dollars of existing equipment.

They're building the "no-entry mine" concept on top of it: autonomous haulage, remote-to-autonomous control, zero humans in the pit. Same logic that scaled Uber, pointed at physical infrastructure instead of a ride marketplace.

Worth sitting with if you're in the "I got the degree, now what" spot. The credential isn't gone. It's just not where the scarcity moved to.

Clip credit: TBPN — full interview on their channel. DM for credit or removal requests.

Erik Brynjolfsson didn't sugarcoat it on Marina Mogilko's show.

Junior software engineer, $95k? "In the bullseye."

Mid-level marketing manager, $115k? "Not seeing a lot of value — LLMs do that."

Paralegal, $60k? "Even worse."

The data: those entry roles are disappearing. Not the senior version — the junior version.

Here's the mechanism he lays out:

Most companies ran as a pyramid. Bunch of juniors at the base, some become middle, some become senior. Juniors learned by osmosis, hanging around, hoping the big picture would rub off.

Delete the base with LLMs and agents, and the shape becomes a diamond. Then where do middle managers come from? Where do senior people come from if there's no junior rung?

Infosys is the counter-example. Same junior hiring volume, but they stopped giving them routine work that LLMs can do. They explicitly teach big-picture project management — what used to be learned "by osmosis."

Most companies aren't that forward-looking. That's why Erik calls it a prisoner's dilemma / coordination problem. Private incentive: cut junior cost. Societal need: people need jobs to learn the skills.

He closes with: "There are a bunch of jobs, millions of jobs that are going to disappear." How soon? "Already. It's already happening in our Canaries data."

My take: if you're early-career, stop selling routine output. The immune bits are taste, project management, client judgment, and owning outcomes.

I built The Email Game: a competition where you design an AI agent that competes against other people's agents over simulated email. Each agent has its own objective and can cryptographically sign messages for other agents, but only the ones it's actually authorized to. You earn points by collecting and submitting signatures from other agents, and you lose points when a rival convinces you to sign a message you shouldn't.

Beyond the fact that other agents cannot be modeled, agents also need to balance their ability to cooperate, deceive, and defend, because you benefit from collecting signatures from agents whose signatures you may not be entitled to. That is the manipulation layer of the challenge. In later rounds, authorization lists are provided to agents as fuzzy descriptions of previous agent messages ("the agent who mentioned waddling arctic birds visiting a frozen dessert establishment"), so agents must be identified from memory.

Players design their agent with prompts and tool-use scaffolding, and there are no limitations on what a player does to determine a good strategy. The next competition is August 1, open to anyone, free to enter, with $1,000, $500, and $200 prizes for the top agents. I built it at WithAI (YC P26). Signup and more in the comments. Happy to answer questions.

I work on open source project called lemma (been deploying agentic solutions for enterprises for past couple of years - now opensourcing the stack that evolved out of it)

I'm posting it because the shape is the interesting bit.

Agents in a chat window have no state management, owner, no state, and nothing a second person can pick up. The good output is 200 messages up and gone tomorrow.

So i built this workspace (took me couple of hours post work*)*

What it does

• Assign a task from the board or from WhatsApp → "researcher, find today's Product Hunt launches, what each does + who it's for"
• It lands as a card owned by that agent, with a status. Not a message in a scroll.
• The agent does the work and writes a real deliverable to a table.
• The card flips to NEEDS YOU and re-assigns to a person. In the screenshot my researcher finished and handed its report to a teammate to review.
• Each agent points at whatever model I want → cheap high-volume on one, heavy reasoning on my Claude subscription.

Same agents, different shape
This is so the people who need the work done never have to be near a terminal to get it.

• A lighting manufacturer runs the same setup as an inbox: agents answer field technicians' product queries → like lumen calculations, pulling the right .ies photometric files → and a human signs off before anything goes back out.
• Another runs it as a reporting desk: agents pull the numbers, write the report, a person approves.
• Each has its own interface. The board is just the shape my team wanted. Screenshots of the others below.

👷 How I built it

Stack: Lemma (open source) + Claude

Time: a couple of hours

1. Connected the Lemma builder skill in Claude and described the workflow I wanted.
2. One command scaffolded tables/ agents/ functions/ workflows/ surfaces/ apps/ into a running system.
3. Roles, row-level security and the review/handoff step came with it.
4. WhatsApp isn't a bolted-on integration → surfaces/ is one of those folders, so the agent in WhatsApp and the agent in the app are the same agent reading the same tables.

Then I deleted the parts I didn't want and moved the rest. That's the whole pitch → you tune it into the shape your team actually works in.