Reddit AI Agent - 2026-06-02¶
1. What People Are Talking About¶
1.1 Engineering discipline is displacing vibe-coding bravado 🡕¶
The highest-signal conversation on 2026-06-02 treated fast AI-assisted delivery as the easy phase and long-term operation as the real work. Across critique posts, production retrospectives, and reliability threads, people kept returning to auth, retries, validation, observability, and re-architecture instead of model cleverness.
u/Aislot argued that “vibe coding” optimizes for speed of creation rather than stability of operation, listing security flaws, scaling problems, race conditions, poor database design, memory leaks, and brittle integrations as the debt that shows up later (VibeCoding is becoming the biggest illusion in software engineering.) (131 points, 16 comments).
u/mitch_eyre_lv said a year of shipping service-business automations taught the opposite ratio from most demos: the “AI layer” was the easy 20%, while auth, per-client data isolation, billing edge cases, retries, and duplicate webhooks were the hard 80% (What actually breaks when you ship AI agents for real service businesses (a year in)) (9 points, 7 comments).
u/DifficultyHead5862 said production hardening mostly meant timeout handling, retry logic, fallback routing, and output validation rather than “interesting AI work,” while u/Jony_Dony (score 1) added that teams still need decision-trace stores because retries do not explain why the agent chose a bad branch in the first place (What does your agent reliability stack actually look like? Not the demo, Production?) (6 points, 10 comments).
Discussion insight: The backlash was not anti-shipping by default. In a second post, u/Aislot argued that major software products often shipped ugly first and re-architected later once demand was undeniable, citing Twitter, Instagram, Facebook, Amazon, and Netflix as precedents (Most of the software you rely on was hacked together fast) (23 points, 3 comments).
Comparison to prior day: Compared with 2026-06-01’s anti-hype mood, 2026-06-02 pushed further into explicit maintenance doctrine: the argument was less “don’t trust the hype” and more “expect infrastructure debt immediately.”
1.2 The community’s default advice is now “single workflow first” 🡕¶
Two high-engagement beginner threads and one enterprise-integration thread converged on the same playbook: learn the basics, ship one narrow workflow, add evals and approvals, and only then reach for multi-agent complexity. The conversation was noticeably less about frameworks and more about sequencing.
u/RecognitionMental943 asked how to start from zero, and u/shazej (score 59) answered with a staged path: basic Python, a simple LLM app, tool use, memory, and retrieval before any LangChain, CrewAI, or AutoGen stack (How would you build an AI agent from zero as a beginner?) (95 points, 43 comments).
u/Signal-Extreme-6615 asked what beginners get wrong, and u/Low-Honeydew6483 (score 21) said the biggest mistake is building a multi-agent system before proving a single agent can do the job; u/Comfortable-Junket50 (score 4) added that people should write 15 to 20 real eval cases before they start changing prompts (What beginner mistake do people make when building AI agents?) (22 points, 44 comments).
u/i_devour_kids asked how to connect agents to real company tools, and u/Positive_Willow_7794 (score 9) said the first step is workflow design: pick one narrow task, separate read-only from write actions, and put approval gates and logs around anything that changes customer data or production systems (How to create an ai agent that actually connects to my company's existing tools?) (25 points, 24 comments).
Discussion insight: The same thread family repeatedly reframed the agent as a junior worker, not a magical feature. u/Positive_Willow_7794 (score 1) said beginner agents should be read-only first, then gain low-risk actions, then gain approval-gated write access only after role, permissions, escalation path, and audit trail are defined (What beginner mistake do people make when building AI agents?) (22 points, 44 comments).
Comparison to prior day: 2026-06-01 already favored narrow deployments, but 2026-06-02 turned that deployment lesson into explicit community teaching advice for both beginners and enterprise teams.
1.3 Working agent deployments remain narrow, operational, and measurable 🡒¶
The deployments people volunteered were still specific, bounded, and easy to evaluate: support triage, SEO writing, research digests, security monitoring, crypto alerts, and job-hunting helpers. General autonomy was far less visible than workflows with one clear output and one clear owner.
In the production-use thread, u/traditionalbaguette (score 22) said an agent now writes blog posts in the author’s house style through October, while u/Routine_Plastic4311 (score 10) said an internal support-triage tool saves hours daily even though “keeping the boundaries clean” became the real work (What's the most useful AI agent you've actually deployed not just demoed?) (58 points, 68 comments).
In the “coolest thing automated” thread, u/Ha_Deal_5079 (score 15) described a multi-agent pipeline that pulls arXiv papers and drops summaries into Slack, while u/itsmars123 (score 12) described a resume-to-landing-page builder and a job-application answer drafter (What’s the coolest thing you’ve automated with AI Agents so far in 2026?) (60 points, 81 comments).
u/rinoyfrancis2 shared VulnWatch, a nightly n8n CVE pipeline that SSHes into a VPS, enriches OSV results with CVSS, EPSS, and CISA KEV data, searches GitHub for exploit PoCs, routes findings through three Claude agents, stores results in PostgreSQL, and triggers human review for critical no-patch issues (Built an autonomous CVE intelligence system entirely in N8N — full workflows on GitHub) (6 points, 2 comments).
Discussion insight: Even the optimistic deployment thread kept circling back to “boring, safe workflows.” u/Ok_Technician_4634 (score 5) said the first use cases that make it into production are usually repetitive, low-risk tasks such as summaries, sprint reviews, customer check-ins, and briefing books rather than flashy autonomy (What's the most useful AI agent you've actually deployed not just demoed?) (58 points, 68 comments).
Comparison to prior day: This stayed consistent with 2026-06-01’s narrow-workflow pattern, but the examples widened into security operations, research digests, and personal productivity instead of centering mainly on messaging and field-service flows.
1.4 Cost, context, and interface friction still set the ceiling 🡒¶
The operational ceiling remained the same cluster as the prior day, but people quantified it more precisely on 2026-06-02. The strongest posts gave concrete numbers for runaway token use, failure windows, and protocol edge cases instead of abstract warnings.
u/Pristine_Rest_7912 said a seven-tool AI content stack overtook the cost of two part-time contractors within about three weeks, and u/PROfil_Official (score 9) argued the hidden cost was paying separate systems to re-derive context that a human would simply remember (We automated half our content pipeline with AI and our monthly costs went from manageable to completely out of control in about three weeks) (72 points, 38 comments).
u/Imbatmanfromyear69bc said a multi-step research agent started contradicting itself after 30 to 40 turns, while u/Few-Abalone-8509 (score 3) said the deeper problem is retrieval timing: agents often store the right constraint and still fail because they do not re-read it before a risky tool call (My agent kept "forgetting" things mid-conversation found a technique that actually solves it (LCM)) (39 points, 25 comments).
u/Available_Treacle635 said a WhatsApp ordering chatbot consumes about 8,000 tokens for a normal customer message and 30,000 to 35,000 tokens when it places a Shopify order, with the attached workflow showing audio, text, image, memory, rating, and follow-up branches in a single flow (Help with token consumption lowering) (3 points, 6 comments).
u/knotalov argued that browser agents often know the plan and fail because browsers are human-first surfaces with stale screenshots, active-tab conflicts, and awkward logged-in sessions; u/bkocdur (score 2) recommended using listing APIs, flight APIs, and GraphQL endpoints directly instead of driving the browser wrapper (After testing browser agents on real web tasks, I think we’re blaming the models for the wrong problem) (7 points, 14 comments).
Discussion insight: The MCP thread showed the same pattern at the protocol layer. u/Sea-Plum-134 reported client-registration failures, refresh tokens outliving user sessions, and scope/permission UX trouble in a production MCP rollout, while commenters said they had to add custom correlation IDs because the spec does not standardize fan-out tracing across multiple MCP servers (Anyone actually running MCP in production yet?) (3 points, 12 comments).
Comparison to prior day: The same cost, memory, and browser limits from 2026-06-01 were still present, but 2026-06-02 added more concrete token counts, session/auth failure modes, and workflow diagrams.
2. What Frustrates People¶
Boring infrastructure work overwhelms the “AI” work¶
The clearest frustration was that production agent work keeps collapsing into infrastructure and recovery logic. u/mitch_eyre_lv said the hard 80% is auth, tenant isolation, billing edge cases, retries, and duplicate webhooks rather than the model layer itself (What actually breaks when you ship AI agents for real service businesses (a year in)) (9 points, 7 comments). u/DifficultyHead5862 said two months of hardening went into retries, fallback routing, and output validation before agents could run unsupervised, while u/Emerald-Bedrock44 (score 3) said real production use exposed edge-case hallucinations quickly enough that the team had to invest in observability instead of adding new features (What's the most useful AI agent you've actually deployed not just demoed?) (58 points, 68 comments). Teams are coping with narrower scopes, more validation, and more traces. Severity: High. Worth building: Yes.
Repeated context reconstruction and token burn wreck the ROI¶
The strongest cost complaint was not just token price, but how often agents re-derive the same understanding. u/Pristine_Rest_7912 said a seven-tool content stack quietly outgrew two contractors within three weeks, and u/PROfil_Official (score 9) said the hidden tax is paying seven systems to reconstruct context a human would have remembered once (We automated half our content pipeline with AI and our monthly costs went from manageable to completely out of control in about three weeks) (72 points, 38 comments). u/Available_Treacle635 added a concrete example from n8n: around 8,000 tokens for a normal WhatsApp message and 30,000 to 35,000 when the bot places a Shopify order (Help with token consumption lowering) (3 points, 6 comments). The workaround today is to automate only the highest-friction steps and keep deterministic routing or non-LLM automation everywhere else. Severity: High. Worth building: Yes.
Human-first surfaces and auth layers break before reasoning does¶
Several threads argued the model often knows what to do and still fails because the surrounding interface is wrong. u/knotalov said browsers create stale-screenshot loops, active-tab conflicts, and messy recovery states, while u/bkocdur (score 2) said many “browser tasks” should really hit listing APIs, flight APIs, or GraphQL endpoints directly (After testing browser agents on real web tasks, I think we’re blaming the models for the wrong problem) (7 points, 14 comments). In the MCP thread, u/Sea-Plum-134 and commenters described refresh tokens outliving user sessions, half-completed client registration, confusing scopes, and no standard way to trace one request across multiple MCP servers (Anyone actually running MCP in production yet?) (3 points, 12 comments). Severity: High. Worth building: Yes.
Memory is still lost at the moment it matters most¶
People are frustrated less by the lack of storage than by the lack of timely retrieval. u/Imbatmanfromyear69bc described long-running agents that contradicted themselves after 30 to 40 turns, while u/Few-Abalone-8509 (score 3) said the failure mode was not missing data but the agent failing to consult the stored constraint before a risky action (My agent kept "forgetting" things mid-conversation found a technique that actually solves it (LCM)) (39 points, 25 comments). The same problem showed up in team handoffs: u/riley_kim said cross-person agent handoffs still rely on humans copying output and rewriting context, and u/pikapikaapika (score 2) said the lossy summary only fails later when the missing detail finally matters (For people running multi-agent setups across a team: how do you handle agent-to-agent handoffs between different people?) (4 points, 12 comments). Severity: Medium-High. Worth building: Yes.
3. What People Wish Existed¶
A real beginner-to-production ramp¶
The biggest beginner threads were not asking for more frameworks; they were asking for a sane path. u/RecognitionMental943 wanted to know what to learn first, and the strongest answers said to start with Python, one simple LLM app, tool use, memory, and retrieval rather than jumping into orchestration stacks (How would you build an AI agent from zero as a beginner?) (95 points, 43 comments). u/Comfortable-Junket50 (score 4) added that beginners need eval sets and traces before they need more architecture (What beginner mistake do people make when building AI agents?) (22 points, 44 comments). This is a practical need, not an aspirational one. Opportunity: Direct.
Enterprise-safe integration and control planes¶
People trying to connect agents to real company systems were effectively asking for a control plane: permissions, approvals, audit logs, and auth that survives contact with real users. u/i_devour_kids asked for something enterprise-ready rather than a weekend chatbot demo, and u/Positive_Willow_7794 (score 9) answered with narrow workflow scoping, read-only/write separation, approval gates, and full logging (How to create an ai agent that actually connects to my company's existing tools?) (25 points, 24 comments). The MCP production thread made the same need more concrete with registration rollback, refresh-token drift, and traceability gaps (Anyone actually running MCP in production yet?) (3 points, 12 comments). Opportunity: Direct.
Exact recall plus durable handoff artifacts¶
The memory discussion and the team-handoff discussion were really the same request in two forms: do not lose important state, and do not force humans to rewrite it. u/Imbatmanfromyear69bc wanted memory that preserves exact prior decisions instead of compressing them away, while u/Few-Abalone-8509 (score 3) said retrieval timing is the missing piece (My agent kept "forgetting" things mid-conversation found a technique that actually solves it (LCM)) (39 points, 25 comments). In parallel, u/Dependent_Policy1307 (score 1) and u/foozlerun24 (score 1) said agent handoffs should be durable artifacts carrying intent, current state, evidence, constraints, permissions, and the next action instead of lossy chat summaries (For people running multi-agent setups across a team: how do you handle agent-to-agent handoffs between different people?) (4 points, 12 comments). Opportunity: Direct, competitive.
Cost-aware routing and token governance¶
People do not just want cheaper tokens; they want a stack that shows when the economics stop working. u/Pristine_Rest_7912 described a workflow whose economics collapsed once seven tools were running together (We automated half our content pipeline with AI and our monthly costs went from manageable to completely out of control in about three weeks) (72 points, 38 comments). u/Familiar_Engine718 then compared OpenRouter, Concentrate.ai, Portkey, and LiteLLM mostly on governance, observability, data redaction, and long-run fee structure rather than raw model count (i evaluated OpenRouter vs Concentrate.ai vs Portkey vs LiteLLM for our llm gateway. an actual comparison.) (6 points, 9 comments). This is a direct practical need, but it is already competitive. Opportunity: Direct, competitive.
Agent-native work surfaces instead of browser-driving¶
The browser-agent thread was effectively a request for a new substrate: isolated workspaces, persistent logged-in state, parallel execution, and direct access to underlying structured interfaces. u/knotalov argued browsers were designed for one human and one foreground tab, not stateful autonomous work (After testing browser agents on real web tasks, I think we’re blaming the models for the wrong problem) (7 points, 14 comments). Existing workarounds are API-first scripts and reverse-engineered endpoints, but the broader request is for an environment that feels native to agents rather than borrowed from humans. Opportunity: Emerging.
4. Tools and Methods in Use¶
| Tool | Category | Sentiment | Strengths | Limitations |
|---|---|---|---|---|
| n8n | Workflow automation | (+/-) | Rapid orchestration across CVE, crypto, WhatsApp, and webhook flows; visible node graphs | Token burn rises when one workflow carries too much reasoning; platform/node quirks and rate-limit workarounds still matter |
| Claude / Claude Code | Model / coding agent | (+/-) | Useful for coding help, analysis/validation/patch agents, and rapid prototyping | Browser-driving is still brittle and long sessions still hit forgetting/context problems |
| Lossless Context Management (LCM) | Memory / context | (+/-) | Immutable SQLite-backed store plus hierarchical summaries preserve exact prior text | Retrieval timing still needs separate trigger logic |
| OpenRouter | LLM gateway | (+/-) | Huge model catalog, single endpoint, single billing, automatic failover | 5%+ fees become noticeable at scale; governance and observability stay thin |
| Concentrate.ai | LLM gateway | (+) | Managed convenience plus PII redaction, RBAC, central key management, and auditing | Smaller model/provider catalog and younger ecosystem |
| Portkey | Gateway control plane | (+/-) | Deep traces, semantic caching, key vault, guardrails, and enterprise controls | Log-based pricing, custom enterprise cost, added latency, and still a separate provider bill |
| LiteLLM | Self-hosted proxy | (+/-) | Zero markup, better data control, low fixed cost at high volume, fallbacks and budgets | Ops burden, scaling work, rougher admin UI, and governance behind the commercial tier |
| MixRoute | Routing / reliability | (+) | Moves retries and failover into config so agent code stays cleaner | Does not solve semantic drift or missing decision traces |
| MCP / MCP gateways | Protocol / middleware | (+/-) | Centralizes auth, permissions, and observability in theory | Client-registration failures, refresh-token drift, confusing scope UX, and no standard fan-out tracing |
| Browser-driving | Method | (-) | Useful when the UI is the only exposed surface | Stale screenshots, active-tab conflicts, token-heavy loops, and awkward logged-in sessions |
Overall: Satisfaction was highest when the tool constrained the problem: n8n for one workflow, LCM for exact recall, MixRoute for retries, and gateway layers chosen explicitly for governance or cost shape. The clearest migration pressures pointed away from browser-driving toward API-first execution, away from generalized stacks toward single-workflow agents, and from managed gateways toward self-hosted LiteLLM once spend becomes large enough to justify ops work (i evaluated OpenRouter vs Concentrate.ai vs Portkey vs LiteLLM for our llm gateway. an actual comparison.) (6 points, 9 comments); (After testing browser agents on real web tasks, I think we’re blaming the models for the wrong problem) (7 points, 14 comments). A notable fallback pattern in the cost thread was to remove AI entirely where API routing and logging are enough; u/FVMF1984 (score 8) explicitly suggested Make, Zapier, n8n, or Python with GitHub Actions for workflows that do not need model reasoning (We automated half our content pipeline with AI and our monthly costs went from manageable to completely out of control in about three weeks) (72 points, 38 comments).
5. What People Are Building¶
| Project | Who built it | What it does | Problem it solves | Stack | Stage | Links |
|---|---|---|---|---|---|---|
| VulnWatch | u/rinoyfrancis2 | Nightly CVE intelligence pipeline with exploit checks and patch suggestions | Manual vulnerability review and patch triage across a VPS | n8n, SSH, OSV API, CVSS/EPSS/CISA KEV, GitHub Search API, Claude, PostgreSQL, human-in-the-loop review | Beta | GitHub · post |
| Ergon GTD bot | u/Jazzlike_Syllabub_91 | Task and project bot that runs inside a larger personal bot system | Keeping a large personal project/task backlog organized across many active bots | Elixir, NATS, LLM parsing; paired with Go/Docker starter stack | Beta | ergon-gtd · ergon-starter · post |
| Kaiju | u/cormacguerin | General assistant and execution kernel for customer-facing agent systems | Building enterprise-ready agents with tools, permissions, and controlled execution | Go, web UI, DAG planner, skill system, intent-based execution gate | Beta | GitHub · post |
| Crypto Monitor | u/Boring-Shop-9424 | BTC price alert workflow that notifies Telegram on meaningful changes | Manual price checking | n8n, CoinGecko, Telegram, Google Sheets | Shipped | post |
| WhatsApp ordering chatbot | u/Available_Treacle635 | Customer-chat workflow that can place Shopify orders from WhatsApp | Handling customer conversations and order entry inside chat | n8n, WhatsApp, Shopify, multimodal branches, memory | Beta | post |
VulnWatch was the most concrete repo-backed build in the set. The post described a nightly workflow that scans a VPS, enriches findings with CVSS, EPSS, and KEV data, checks GitHub for exploit proofs of concept, and then routes each CVE through analysis, validation, and patch stages before human review for critical no-patch cases (Built an autonomous CVE intelligence system entirely in N8N — full workflows on GitHub) (6 points, 2 comments). The public repo describes the same system as an “Autonomous CVE intelligence system” that validates exploitability with Claude AI and alerts with exact patch commands (GitHub).
Ergon GTD bot and Kaiju show that open-source builder activity is splitting into two layers: personal workflow bots and reusable execution kernels. The Ergon README presents the project as a GTD bot with inbox parsing powered by an LLM and a message interface built on NATS, while the paired starter repo is a Go/Docker bootstrapper for running a wider bot ecosystem (ergon-gtd; ergon-starter). Kaiju pushes in the other direction: its README pitches a conversational assistant plus an execution kernel that plans tool-call DAGs, runs them in parallel where possible, and enforces an intent-based execution gate at runtime (GitHub).
Crypto Monitor is small, but the workflow screenshot makes the builder pattern unusually legible: schedule trigger, CoinGecko fetch, current-price save, previous-price lookup, change check, Telegram alert, and sheet update. It is a useful reminder that many deployed “agent” wins are really compact, deterministic automations with one alerting step, not sprawling autonomous systems (My Crypto Monitor is live) (5 points, 3 comments).
WhatsApp ordering chatbot is significant mainly because it shows the opposite pattern: one workflow that has accumulated too many branches. The image and description show audio, text, image, memory, rating, and follow-up paths combined with an order-placement action, which explains why token usage spikes so hard once the bot leaves simple chat territory (Help with token consumption lowering) (3 points, 6 comments).
Common builder pattern: The builds on 2026-06-02 mostly fell into two camps: narrow workflow automations with obvious business value, or reusable infrastructure for keeping those workflows reliable and inspectable. In both camps, the trigger was a specific pain point — security triage, task overload, price checking, or chat-based ordering — rather than a generic desire to “build an agent.”
6. New and Notable¶
Team-scale agent handoffs are becoming their own infrastructure problem¶
u/riley_kim described a gap that did not show up as clearly in earlier days: when one person’s agent needs to hand work to another person’s agent, the bridge is often still a human copying output and rewriting context by hand (For people running multi-agent setups across a team: how do you handle agent-to-agent handoffs between different people?) (4 points, 12 comments). The strongest replies treated the handoff as a durable artifact problem, not a prompt problem: u/Dependent_Policy1307 (score 1) and u/foozlerun24 (score 1) said the minimum packet should include intent, current state, evidence, constraints, permissions, and a clear next action. That is a more concrete articulation of “shared state” than the broader memory discussions from prior days.
MCP is leaving localhost and running into auth, session, and tracing reality¶
u/Sea-Plum-134 said the hard part of a production MCP rollout was not the spec itself but what happened around it: failed client registration, refresh tokens outliving real sessions, and permission prompts that made users uneasy (Anyone actually running MCP in production yet?) (3 points, 12 comments). Commenters added two concrete operator lessons: tie token lifetime to the actual session, and treat registration as a rollback-capable transaction rather than a chain of optimistic steps. That makes MCP feel less like a toy integration topic and more like a new auth/observability surface that still lacks standard operational patterns.
7. Where the Opportunities Are¶
[+++] Enterprise control planes for permissions, approvals, and auditability — The enterprise-tools thread, the beginner-mistakes thread, and the MCP production thread all pointed to the same gap: read/write separation, approval gates, session-aware auth, and replayable logs before agents can touch real systems safely.
[+++] Cost and memory governance for long-running agents — The cost-blowout post, the LCM thread, the WhatsApp token-burn example, and the gateway comparison all showed the same need: budget visibility, exact recall, retrieval triggers, and better rules for when a workflow should stop or fall back.
[++] Shared state and handoff artifacts across people and agents — Cross-person agent handoffs are still lossy and manual. The comments on the handoff thread were unusually specific about what the missing artifact needs to contain: intent, state, evidence, permissions, and next action.
[++] API-first work surfaces that replace browser-driving — The browser-agent discussion made a strong case that many “web tasks” are really undocumented API tasks. There is room for products that discover, authenticate to, and expose those structured surfaces directly to agents.
[+] Guided starter kits with eval-first defaults — The beginner threads were effectively asking for opinionated ramps: one workflow, one eval set, one trace view, and staged authority increases instead of a framework zoo.
8. Takeaways¶
- The day’s strongest consensus was about engineering discipline, not model magic. The highest-signal post argued that vibe coding hides the real work of security, scaling, and integration, and multiple production threads said retries, validation, and traceability dominate once agents leave demo mode. (VibeCoding is becoming the biggest illusion in software engineering.) (131 points, 16 comments)
- The community is standardizing on a staged adoption path. Beginners and enterprise teams were both told to start with one narrow workflow, prove it with evals and logs, and add permissions gradually instead of jumping straight into multi-agent systems. (How would you build an AI agent from zero as a beginner?) (95 points, 43 comments); (How to create an ai agent that actually connects to my company's existing tools?) (25 points, 24 comments)
- Real deployments are still narrow, measurable, and mostly operational. The concrete wins were support triage, SEO writing, research digests, CVE monitoring, and compact alerting workflows rather than broad autonomous agents. (What's the most useful AI agent you've actually deployed not just demoed?) (58 points, 68 comments); (Built an autonomous CVE intelligence system entirely in N8N — full workflows on GitHub) (6 points, 2 comments)
- Cost ceilings are now being quantified in workflow terms. One team said seven AI services overtook two contractors in roughly three weeks, and another builder showed a single WhatsApp order flow hitting 30,000 to 35,000 tokens in one interaction. (We automated half our content pipeline with AI and our monthly costs went from manageable to completely out of control in about three weeks) (72 points, 38 comments); (Help with token consumption lowering) (3 points, 6 comments)
- Shared state is becoming the next bottleneck after memory. The memory thread wanted exact recall and retrieval triggers inside one agent, while the handoff thread wanted durable cross-person artifacts so humans no longer have to act as the bridge between agents. (My agent kept "forgetting" things mid-conversation found a technique that actually solves it (LCM)) (39 points, 25 comments); (For people running multi-agent setups across a team: how do you handle agent-to-agent handoffs between different people?) (4 points, 12 comments)