HumanLoop

HumanLoop AI

HumanLoop AI

HumanLoop AI

HumanLoop AI

HumanLoop AI

HumanLoop AI

HumanLoop AI

HumanLoop AI

HumanLoop AI

HumanLoop AI

Passed Claude CCA-F with 10+ teammates — notes and prep advice

Over the past few weeks, 10+ people on our team have taken and passed the Claude Certified Architect – Foundations (CCA-F) exam. After comparing notes, our main takeaway is: This is not really an API memorization exam. It is much closer to a scenario-based architecture judgment exam. You are not just asked whether you know a Claude feature. You are asked whether you can make reasonable design trade-offs when Claude is used inside real products, agent workflows, developer tools, and automation systems. Some of the recurring questions are more like: Should this task be handled by one agent or multiple sub-agents? Is this tool doing too much? Are the permissions too broad? Is MCP actually needed here, or is it over-engineering? Should this action be automated, or should there be human review? How should structured output be validated? How should long-context workflows be managed reliably? What is the safest next step in a partially automated system? Here are our notes for anyone preparing for the exam. 1. Basic exam structure Based on the official outline and public exam writeups, the exam is: 120 minutes Multiple choice 4 options per question Score range: 100–1000 Passing score: 720 The exam domains are: Agent architecture and orchestration — 27% Tool design and MCP integration — 18% Claude Code configuration and workflows — 20% Prompt engineering and structured output — 20% Context management and reliability — 15% One public writeup also mentioned that there are 6 scenario categories, and the exam randomly selects 4 of them. So this is not a “random facts about Claude” exam. It is much more about reading a realistic scenario and choosing the safest, simplest, most appropriate architecture. 2. The three principles that kept coming up After reviewing the questions we struggled with, we found that many of them came back to three design principles. 1. Least privilege Do not give a tool, agent, or workflow more access than it needs. Examples: If read-only access is enough, do not grant write access. If access to one repository is enough, do not grant access to the whole workspace. If a tool only needs one narrow action, do not expose a broad system-level capability. If an action is high-risk, do not fully automate it without review. A lot of wrong answers look attractive because they are powerful or automated. But they often give the model or tool too much authority. 2. Single responsibility A tool should not do everything. A sub-agent should not become a “general-purpose employee” that retrieves data, makes decisions, modifies files, submits changes, and notifies people all in one step. Many questions test whether you understand where the responsibility should live: Should this be a tool? Should this be agent reasoning? Should this be a human decision? Should this be a separate validation layer? Should this be split into smaller components? If one component is doing too much, be careful. 3. Avoid over-engineering This was probably the biggest pattern. Some answers look sophisticated: Multi-agent orchestration Complex MCP workflows Long-term memory Fully automated tool execution Multi-stage validation pipelines But if the problem is small, narrow, and low-risk, the best answer is often the simplest controlled solution. Our internal summary was: Do not choose the most impressive architecture. Choose the smallest, safest, most controllable one. 3. English reading is a real hidden challenge For non-native English speakers, this may be one of the hardest parts. The questions are often long scenario descriptions. They may include: the current system design the team’s goal existing constraints the risk profile what tools are available what the next step should be The answer choices can also be long. Sometimes one word changes the meaning of the whole option. Words like: automatically always unrestricted without review full access all repositories execute directly can make an option much riskier than it first appears. So our advice is: Practice reading English scenarios directly. Do not rely on translation tools. During the actual proctored exam, you should not expect to use Google Translate, Chrome translation, DeepL, Claude, ChatGPT, or any other external translation tool. For the last few days before the exam, it is worth forcing yourself to read only English material and English practice questions. 4. ProctorFree exam setup The exam is online and uses ProctorFree. The rough flow is: You receive the exam email. You follow the exam link. You download and install ProctorFree. You complete the pre-exam setup. The system checks camera, microphone, network, and screen recording. You start the exam. The session is recorded. After submission, you wait for the upload to complete. Practical setup tips: Use only one monitor. Disconnect external displays. Close unnecessary applications. Clos

Six agents running. Three are paused waiting for me. I haven't written a line of code in two hours.

I've been running parallel Claude Code agents for a few months. The promise was speed - 5× the throughput because 5× the agents. What actually happens by hour two: One agent stops on a yes/no. You alt-tab to it, approve, alt-tab back. Two more pause within the next minute. You scroll through their context, lose your place in the first one. Now there are four waiting. You're not writing code anymore - you're processing a decision queue you accidentally built for yourself. The agents aren't slow. You are. I started calling this the bottleself: the point where parallelism stops adding output and starts adding approvals you can't process fast enough. The ceiling on your system isn't tokens, model speed, or context window. It's the human in the loop. So I built a layer above the agents - a planner that: takes a high-level goal decomposes it into parallel subtasks spawns parallel Claude Code sub-agents - one per task has a QA sub-agent review the output pings you only when it actually can't decide Right now it's Claude Code only. Codex / Cursor / Aider integrations next. For a fresh repo with Claude Code, the planner handles decomposition + parallel execution end-to-end without me touching the keyboard. Source: github.com/gekto-dev/gekto Try: npx gekto Honest question to anyone running 5+ agents: how much of your day is actually writing code vs clearing the queue your agents created? Where does the bottleself hit for you? submitted by /u/OptimisticYogurt42 [link] [comments]

A plugin that slows you down on purpose

Hi all. Out of respect to other humans this is written by a human. You all should take an Uber to get to the carwash. My name is Ilya and I want to share my ecosystem of skills and agents (and a couple of rules + hooks) that I've built for myself over the past 5 months because I wasn't happy with anything that the market currently offers. I use it on daily basis, and it only contains stuff that I needed to solve problems I faced, and I'm super happy with how it works. Quick context: currently I work in strategy consulting. But I got lucky enough to get consistent exposure to managing people for over 20 years. Running my own business, turning around others' businesses, playing colony management games, managing consulting teams, and most importantly - managing a mid-sized guild in an MMO (if you've done this you know). I am not a software engineer, although I do code a bit. The main idea was to organise AI in a way I would organise a team of very capable people. So this is mostly for thinking work, including coding, not just for coding. --- Why slow AI gives us speed. It's good, but the flip side - it's bad in some situations, and I see that many people miss it entirely. AI is great at following directions. If the direction is wrong because you rushed it, the wrong thing gets executed very quickly. The fix is unsexy and requires patience: spend time on the brief upfront, make the AI push back when something doesn't make sense, then check what came out before stacking the next step on top. Feels slower, is slower at first. But you end up with what you actually wanted instead of another slop-fest, so it's net faster eventually. --- The 7 principles I've built this on Slow is fast - to own the understanding you can't rush Bad communication kills results (human-to-human, human-to-AI, and human-to-self - we're often misleading ourselves thinking that we know what we want) We don't know what we don't know - AI must help you to see outside of your bubble Any computer task is doable by AI if AI is properly organised - tasks are small enough, well defined, and well assessed Solve for problems that exist now, not theoretical or aspirational ones, to stay focused (and save tokens) Context is king - shit in, shit out AI can help you deal with AI - especially by doing the boring organisational work for you --- Two examples of how it works to start with /shaping - my most-used skill. It's a small workflow where orchestrator uses 3 underlying skills in a dialogue mode and helps me to frame the problem depending on where I am in my understanding of it. It solves multiple problems - more often than desired, I think I know what the problem is, but in reality the problem is somewhere else. Often, it helps me to find a better (and simpler!) solution. This is somewhat similar to why companies pay for consulting - because they know that finding the right question is 90% of the answer. This is, as you guessed, slow - but it helps to improve defining the direction for work. Which is a big deal in management, including managing AI. /critic - this is when it comes to comparing what was produced to what was intended. It invokes a subagent, that is taught to assess the quality of stuff produced. It then gives an actionable unbiased feedback. Obviously, if the direction was wrong, there won't be much value in it, but when the direction is right - it does miracles for me. Works best for non-code artefacts (PRD, architecture, skills, slides, written documents). Together they bracket the work - shaping at the start to figure out what's actually being asked, critic at the end to check the output matches it. --- What's in it Four plugins (title is a bit misleading for controversy, sorry), MIT. Each works alone, but they compose: - rageatc-core - thinking infrastructure. Ideation, understanding, solutioning, briefing, research, producer-critic-learner loops, writing skills, persuading. The most-used plugin. - rageatc-tech (small one) - a bit of extra tools the agent can reach: browse, PDFs, with fallbacks when primary tools aren't available. - rageatc-code - software building the slow way. An improved version of Superpowers by Jesse Vincent embedded in my workflow. TDD enforced, architecture before code, scale-adaptive. Heavy on persistent project knowledge - PRD, architecture, roadmap, orchestration plan. - rageatc-design - design systems for UI work. Greenfield or extracted from existing code. This is an amazing interface-design by Damola Akinleye embedded in my workflow. Most software work uses all four. Non-coding work usually only needs core and tech. --- vs Superpowers rageatc-code draws heavily from Superpowers by Jesse Vincent - TDD enforcement, worktree isolation, verification discipline. What rageatc-code adds on top: persistent project knowledge (PRD, architecture, roadmap that survive sessions), scale-adaptive workflow (matches rigour to project size), and tight integration with rageatc-core'

The AI council from the thread a few days bac the waitlist is open

I posted about an AI council tool I had built with claude to help me manage my life. Five people asked to be notified after I packaged it up for public use. This is the notification. It is called Hierocles, after the second-century Stoic who described human responsibility as a series of concentric rings. Yourself first, then your household, then your community, then the wider world. Each ring depends on the one inside it. The mechanics are mostly what I described in the original thread. Five specialist advisors across body, finance, mind, projects, and a chief of staff who synthesises. A 90-second daily check-in. Fragments numbered across all time. Vector memory that surfaces what you wrote three months ago when it becomes relevant. A weekly review on Sundays. The one thing that has changed since the original thread the rings now unlock in sequence. You start with ring I (the self). You stay there until it holds. Ring II opens when you have demonstrated sustained adherence in ring I The system removes the choice to move ahead too quickly. The interface has also been rebuilt. The original was a text-based tool I was running for myself. The version going into private testing has a proper UI with council member animations, daily and weekly review screens, and the fragment archive in a form you can actually navigate. It is in private testing because some of the work that comes between "running it for myself" and "letting strangers trust it with their lives" is the work that does not show up in the marketing copy. Prompt injection defence on every input the council reads. Per-user vector isolation so fragments never cross between accounts. Server-side API handling with rate limits and token budgets so a runaway loop cannot quietly produce a five-figure Anthropic bill. The kind of thing that is invisible when it is working and catastrophic when it is not. The waitlist is at www.hierocles.app One message when it ships. No drip sequence. To the people from the original thread who asked to be notified u/OwnAd2284, u/Long-Woodpecker-1980, u/normalbrain609, u/Moist-Wonder-9912, u/toughtacos Happy to answer questions. I will be in the thread for the next few hours. submitted by /u/Glittering-Pie6039 [link] [comments]

18 months running Claude as the dev companion for my automated news site - Feedback needed

Hi, I started my project about 18 months ago because I was sick of opening 10 tabs every morning to figure out what happened in AI that day. So I built it using Claude Code (starting from Research Preview). A scraper that reads around 60+ sources, clusters topics, then Claude writes one synthesis article per cluster. No humans in the loop. I started iterating on this, and now I have an automated news website: digitalmindnews.com And to be honest... the stats... they're bad ;-P SEO has been rough (Google clearly doesn't love AI-written news), traffic is small, indexing is a pain. Commercially this isn't a thing. But me and my friends actually use it as a morning digest instead of bouncing between TechCrunch, Anthropic, OpenAI announcements, Decoder etc. So in the "tool I wanted to exist" sense it works for us, which is kind of why I built it. Anyway I've been head down on this for 18 months and can't see it from outside anymore. Two things I'd love input on: what's broken on first look at the site itself? for anyone else running Claude in a long-running production loop: what gotchas have you hit? Model-update regressions, prompt drift, output quality drift, cost spikes. I'm curious what your war stories are? Oh and tip from my side: a dream project can be iterated forever, but after 18 months I realized I'm polishing the stone for myself :-( submitted by /u/Se4h [link] [comments]

AI Agents Need Rollback More Than They Need Autonomy

I have been thinking about transactions in most agent frameworks. Consider an agent executing a sequence of five tool calls. If the third tool encounters an error, the resulting state is neither the user's intended outcome nor the system's state before execution began. Consequently, the agent has no systematic way to recover, and even a human operator must reconstruct what happened from incomplete evidence. This issue is not a problem with the tooling itself; it is a fundamental primitive missing from the stack. Databases have addressed this problem for 50 years, and distributed systems have been grappling with it for decades. A rich terminology exists to articulate this concept: ACID, sagas, compensating actions, idempotency keys, two-phase commit, and write-ahead logs. Maybe some of these concepts have been incorporated into agent frameworks, but I haven't encountered them in production so far. Currently, the prevailing pattern is as follows: - Execute a sequence of tool calls. - If an error occurs, request the LLM to "figure it out." - Remain hopeful for a favorable outcome. - Log "task complete" when the loop concludes. This approach proves effective when agents perform reversible actions within isolated environments. However, it fails when agents interact with file systems, deployments, external APIs with side effects, payment flows, or databases, all of which a human would expect to behave transactionally rather than leaving partial state behind. The question is not "How autonomous can we make agents?" but rather "How can agents express their intent over operations that necessitate retries, compensation, or rollbacks?" Will making the LLM intelligent enough to handle these situations be enough? This is the same mistake distributed systems already made, assuming that the application layer would independently resolve these issues. That assumption proved incorrect, and the infrastructure had to take the lead. The promising next generation of solutions will likely deviate from the concept of smarter loops and instead focus on the following: - Establishing explicit transaction boundaries. - Registering compensating actions for each tool. - Incorporating idempotency keys into tool calls. - Utilizing replay logs that extend beyond mere chat history. - Recognizing approval gates as first-class primitives. - Implementing partial-failure recovery mechanisms that do not require the LLM to engage in reasoning. Or am I way off? Let me know your thoughts. submitted by /u/wesh-k [link] [comments]

Serious question: if humans vanished tomorrow how long would AI civilisation last?

I think a lot of AI discourse quietly skips over dependency chains. If humanity disappeared tomorrow what exactly happens to current LLMs? A lot of people talk about these systems as if they are proto civilisations waiting to escape human limitation and continue evolving independently. But would they? When you strip away all the hype modern AI still sits on top of an enormous inherited stack of human structure: Human language Human memory Human labelled reality Human built infrastructure Human maintained datacentres Human energy grids Human chip manufacturing Human feedback loops Human incentives Human institutions Even the “intelligence” itself is trained almost entirely on compressed human civilisation. I now understand models can generalise. They can infer patterns. They can form internal abstractions beyond rote memorisation. That part is clearly true. But inference over WHAT? Remove humans entirely and current systems do not continue building civilisation they gradually become disconnected from reality itself. So: No new grounding data. No maintenance. No semiconductor supply chain. No evolving human context. No fresh interaction with the physical world. No repair of infrastructure. Eventually the system is inferencing over increasingly stale representations of a civilisation that no longer exists. This is where I think a lot of AI discussions become confused. People collapse several completely different concepts into one another: Pattern prediction > consciousness Generalisation > agency Output fluency > autonomy Intelligence > independence The closer some people get to the technology the more they seem to mistake functional capability for a superior lifeform emerging lol. To me current AI looks less like an independent civilisation and more like a gigantic mirror of human civilisation itself. An extraordinarily powerful mirror. But still a mirror. Curious where people agree or disagree with this? submitted by /u/MediumLibrarian7100 [link] [comments]

Why I added a governance layer on top of my Claude agents (and why it made a huge difference)

Hey r/ClaudeAI, I’ve been heavily using Claude 3.5 Sonnet and Opus through the Anthropic API to build agents and workflows. Claude is honestly one of the best models right now for complex reasoning and tool calling. But here’s what I kept running into: even though Claude is smart, when I put it into longer-running agent loops (CrewAI, LangGraph style setups), it still does the classic agent things occasional silent failures, burning through tokens in loops, or just going off in directions I didn’t expect. The worst part wasn’t even the cost. It was the constant checking. I couldn’t fully trust the agent to run for hours without me babysitting it. So I started using a lightweight governance/observability layer that sits below the agent (not inside the system prompt). It basically adds: Hard safety boundaries and fail-closed behavior Real-time live traces so I can actually see what Claude is doing step by step Human-in-the-loop control (I can pause, resume or stop the agent from Telegram/phone) Automatic checkpointing Proper runtime budget caps (not just “please don’t spend too much” in the prompt) The difference is night and day. I can now let my Claude agents run for long periods and actually feel safe ignoring them. Curious if other people building with Claude have run into the same trust/cost/monitoring issues. Have you tried any governance tools or patterns that made your Claude agents feel truly production-ready? Or are you still manually monitoring them? Would love to hear what’s working for you. submitted by /u/Necessary_Drag_8031 [link] [comments]

Built an agentic RAG over my Obsidian vault so Claude could read engineering books I never have time for. Then I built the eval harness to check Claude wasn't lying to me.

For context, I posted on Medium a while back about burning through Claude Code's weekly limit in 3 days. The token bleed problem from that post is what kicked off this project. Short version of the workflow: Convert engineering PDFs to markdown, drop them in an Obsidian vault Cheap agent (Kimi K2.5) does BM25 retrieval over the vault Claude only sees the relevant chunks, not the whole book Token cost per question dropped from ~50k to ~5k That part worked. The new problem: the agent was sometimes confidently wrong, and I couldn't tell. Saying things like "Marcus Aurelius wrote about death in Book IX section 3" when the canonical passage was actually in Book IV section 5. Plausible enough that I wouldn't catch it unless I went and verified manually. So I built an eval harness. Most of the work ended up being on the LLM judge. I used Claude Sonnet 4.6 as the judge, deliberately a different model family from the Kimi agent so the judge isn't grading its own output. First rubric had four discrete buckets including a 0.7 "thin but not wrong." On hand-grading, my human grader (me, blind, on a different day) also collapsed everything borderline into 0.7. Judge and human were both reaching for the same wrong bucket. The agreement number looked respectable but was actually measuring shared bias. Four rubric iterations later, the version that worked collapsed the middle bucket entirely and added a 0.9 bucket for one specific case: "right answer, wrong chunk." This is when retrieval missed the canonical source but the agent answered correctly from an equivalent passage. Before that bucket, this case was either a false positive (1.0 papering over a retrieval miss) or a false negative (0.4 punishing a correct answer). The split is what fixed it. Under the new rubric, judge agreement with human on 18 rows went from 7/18 (39%) to 17/18 (94%). Caveats so I'm honest about it: 18 rows is a small sample. Adversarial slice is the next round of work. Single grader. Inter-grader reliability not established. BM25 isn't novel. I picked it because in technical and literary corpora, query/document vocabulary overlap is high enough that embeddings don't add much. I also have one negative result that surprised me: the same chunking technique that lifted one corpus by 33pp regressed another by 17pp on the same eval. The harness caught it on the first run. Wrote up why. Full writeup with the four-iteration rubric story, the calibration worksheet showing per-row shifts, and the negative-result note (GitHub repo is linked at the bottom of the post): https://medium.com/@kunalbhardwaj598/i-gave-claude-full-engineering-books-to-read-then-built-the-eval-harness-to-check-it-wasnt-lying-e9354bf6fa96 Specifically curious about: anyone else here using Claude Sonnet as their judge for their own RAG/agent setups, what rubric you landed on, and how you're handling the inter-grader reliability problem with a single human in the loop. submitted by /u/More-Hunter-3457 [link] [comments]

Stanford studied 51 real AI deployments and found a 71% vs 40% productivity gap - here's what separates the two groups

I came across a Stanford research paper that actually went inside companies running AI in production - not pilots, not surveys, real deployments. They found something that stuck with me. Companies using what they call "agentic AI" - where the AI owns the task start to finish with no human approval loop - are seeing 71% median productivity gains. Companies using standard AI that assists humans are averaging 40%. Same technology. Nearly double the output. The kicker: only 20% of companies are in the 71% group. A few things that stood out from the actual data: A supermarket replaced its entire buying process with AI - waste down 40%, stockouts down 80%, profit margin doubled A security team went from 1,500 alerts/month to 40,000 with the same headcount Stanford identified 3 conditions required before agentic AI works: high-volume tasks, clear success criteria, and recoverable errors Most companies apparently can't name all three for their current setup. Full report here if you want to dig into the numbers: https://digitaleconomy.stanford.edu/app/uploads/2026/03/EnterpriseAIPlaybook_PereiraGraylinBrynjolfsson.pdf Here is a full breakdown with all the data if you want to dig deeper: https://youtu.be/JePxda9ZGQE What's the AI setup at your company - closer to the 40% group or the 71% group? submitted by /u/MaJoR_-_007 [link] [comments]

Max 20x ($200/mo): Neither the 2x session nor 1.5x weekly limit increase applied to my account. Math proof inside. Zero response from support.

I pay $200/month for Max 20x. Been on Claude Code since September 2025. I use it heavily, 95% Claude Code. Anthropic announced two limit increases: - May 6: 2x session limit for all paid plans ("effective today") - May 13: 1.5x weekly limit for all paid plans through July 13 ("nothing to opt into") Neither has been applied to my account. I can prove it with math. **The numbers** Started a fresh session at 0% on everything. After one session of normal Opus usage: - Session: 90% used - Weekly (all models): 12% used That means one full session = ~14% of weekly. This is the exact same ratio from before May 6. Nothing changed. **What the ratio should be** | Scenario | Per session | Sessions/week | Weekly capacity | |---|---|---|---| | Old baseline | 14% | 7 | 1x | | 2x session only | 28% | 3 | 1x | | 1.5x weekly only | 9% | 10 | 1.5x | | Both applied | 19% | 5 | 1.5x | | **What I see** | **14%** | **7** | **1x** | I match the old baseline row. Neither increase is active. I am getting 1x weekly capacity. Everyone else on the same plan is supposed to get 1.5x. I am paying $200/month for 66% of the advertised service. **Support is non-existent** - I contacted claude.ai support on May 8. The bot had no knowledge of the May 6 announcement. It deflected to old promos from March and Holiday 2025. Asked for screenshots I already gave. No escalation to a human. Conversation dead-ended. - Filed GitHub #57146 on May 8. Zero responses. Not even a "we see this." - Filed GitHub #59525 on May 16 with full math breakdown and screenshot. Waiting. - Emailed support@anthropic.com. Waiting. There is no phone number. No ticket system. No human escalation. The claude.ai support bot reads nothing you say and loops through irrelevant troubleshooting. It exists to make you feel like you contacted support without actually providing any. The only thing that works is posting on social media, which only works if you have a big following or if a post goes viral. People with 50 followers and people with 50,000 followers pay the same $200. Only one group gets their issues resolved. That is broken. **What I need** A human to look at my account and confirm whether the increases are active. If not, apply them. That is it. Every week this stays broken, I lose capacity I will never get back. The promo ends July 13. I have already lost the weeks of May 10 and May 17. I am considering abandoning this account for a fresh one just to see if a new account gets the right limits. I would lose all my settings, memory, and chat history. The fact that this is even on the table shows how badly the support system has failed. GitHub issue with full details: https://github.com/anthropics/claude-code/issues/59525 Is anyone else seeing this? Has anyone actually gotten limit issues resolved through support? submitted by /u/Intelligent-Ant-1122 [link] [comments]

Built a structured workflow layer on top of Claude Code - looking for active contributors

I've been building claude-code-harness (github.com/anudeeps28/claude-code-harness) over the past few months - it's an open-source framework that brings structure and reliability to Claude Code workflows. What it includes: - 16 slash command skills - 14 sub-agents with deliberate model routing (right model for the right task) - Node.js hooks for lifecycle control - Tracker adapters for Azure DevOps and GitHub - Human gates at every critical phase - the core philosophy is that AI should amplify your judgment, not replace it I use this daily in my job as an AI Engineer, and it's become the backbone of how I build and ship AI systems. What I'm looking for: Contributors who care about this problem space - building AI systems that are structured, auditable, and human-in-the-loop. Not just people who want to merge PRs, but people who have opinions about how Claude Code workflows should work. If you've been using Claude Code heavily and have ideas, pain points, or want to contribute skills/subagents - I'd love to connect. Drop a comment or open an issue on the repo. Happy to answer questions about the architecture too. submitted by /u/lofty_smiles [link] [comments]

The Trust–Oversight Paradox: As AI Gets Better, Humans May Stop Really Overseeing It

I think one of the biggest AI risks may be starting to flip. Earlier, the fear was: “What if AI is wrong too often?” But now I think the deeper risk may become: “What happens when AI becomes right often enough that humans stop meaningfully questioning it?” In many enterprise systems, oversight slowly changes shape. At first: humans review everything carefully. Then: they review only exceptions. Then: they skim explanations. Then: they approve unless something looks obviously wrong. Eventually, oversight becomes routine instead of judgment. That creates what I’m calling the Trust–Oversight Paradox: More AI accuracy → more human trust → less meaningful scrutiny → harder governance when failure finally happens. And the dangerous part is: high-performing AI can still fail through: incomplete representation, stale data, hidden dependencies, edge cases, wrong escalation logic, automation bias, or overconfident reasoning. The model may not hallucinate. It may simply reason correctly on an incomplete version of reality. I increasingly feel this becomes important for: enterprise AI, agentic systems, AI copilots, autonomous workflows, banking, healthcare, compliance, and large-scale operational systems. This is also why I’m starting to think “human-in-the-loop” is not enough. Maybe the future is not: “Humans reviewing every output.” Maybe the future is: humans governing the boundaries within which AI is allowed to operate. Curious what others think. submitted by /u/raktimsingh22 [link] [comments]

Anthropic built the agentic features. Now they're billing them separately.

Starting June 15, Claude subscribers get a separate monthly credit for Agent SDK and claude -p usage: $200/mo for Max 20x, $100 for Max 5x, $20 for Pro. Once you burn through it, programmatic usage stops unless you've opted into extra usage billing at API rates. Your interactive Claude Code and chat usage stays on the subscription pool, untouched. I spent the last day digging into the community reaction across Reddit, GitHub, HN, and tech press. Tracked roughly 120 distinct opinions. Here's what I found. The sentiment split About 60% negative (credit is too small, feels like a value regression) About 25% pragmatic ("this was inevitable, the old model was broken") About 15% neutral to supportive ("interactive use is untouched, this is fair") Theo Browne (T3.gg) put it bluntly: anyone using T3 Code, Conductor, Zed, or claude -p in CI scripts had their effective usage cut by 25x. He said he now has to make the Claude Code experience on T3 Code "significantly worse." Ben Hylak (co-founder of Raindrop.ai) responded: "This is either really silly, or shows how bad of a spot Anthropic is in re: GPUs." Theo also said: "Framing this as a free credit instead of a regression for users is wild." That tracks with what I'm seeing across the threads. The telco parallel This follows the exact playbook telcos used with "unlimited" data plans. Sell unlimited. Watch users actually use it. Introduce a Fair Usage Policy that throttles heavy users. Continue marketing the plan as unlimited. Anthropic marketed Claude Code as an all-in-one agentic platform. They shipped Routines, /goal, /loop, scheduled tasks, and cloud sessions as headline features. Users adopted those patterns. Then the compute math didn't work out, and instead of solving the infrastructure problem, they drew a billing boundary inside their own product. Where the telco analogy breaks: Anthropic is capacity-constrained in ways telcos never were. They're spending aggressively on compute, and the resource contention isn't fabricated. But resource contention is an infrastructure problem, not a billing problem. And as we'll see, Anthropic did build the infrastructure to solve it. The question is why claude -p doesn't benefit from it. The contradiction that cuts deepest Here's what most people haven't articulated yet. Anthropic's product roadmap over the last 3 months has been aggressively agentic: Routines (cloud-hosted, schedule/webhook/GitHub triggers, no human in the loop) /goal (autonomous execution with minimal input) /loop (persistent in-session repetition) Scheduled tasks (desktop recurring prompts) Agent View (multi-session monitoring dashboard) Remote Control (manage sessions from phone) Every one of these features trains users to treat Claude Code as an always-on autonomous system. Anthropic productized exactly the usage pattern that the "you should use the API" crowd says doesn't belong on a subscription. But here's the catch. Routines draw from your regular subscription pool. claude -p doing the same work draws from the new capped credit. The billing line isn't "interactive vs agentic." It's "first-party agentic vs everything else." claude -p is the unix-philosophy composable interface for Claude Code. Penalizing users for calling the same primitive directly instead of wrapping it in Anthropic's GUI is anti-composability. If it were purely about cost management, Routines would also draw from the SDK credit. They don't. The distinction is about who controls the agent runtime. Then there's Managed Agents, Anthropic's API-side agent harness that entered public beta in April. Fully hosted runtime with cloud containers, built-in tools, and prompt caching baked in. API billing, pay-as-you-go. So now there are three tiers: Tier 1: Routines (subscription). Anthropic-hosted, flat-rate. They control the runtime, they optimize caching. Tier 2: Agent SDK / claude -p (credit). Your runtime, your code. Hard-capped. Caching APIs exist but you're on your own to implement them. Tier 3: Managed Agents (API). Anthropic-hosted again. Pay-as-you-go, but with full caching and compaction. Tiers 1 and 3, where Anthropic controls the runtime, get either flat-rate billing or optimized infrastructure. Tier 2, where you control the runtime, gets the worst deal. The strategy isn't "interactive vs programmatic." It's "managed vs unmanaged." The credit system is the squeeze play pushing you toward one of their managed options. Here's the nuance: prompt caching IS publicly available via the API. Agent SDK developers can use it. Cache reads cost 10% of base input token price. The optimization isn't gated behind Managed Agents. So why did third-party tools burn so many tokens? Many were unoptimized for Anthropic's caching compared to first-party tools. That resource contention was partly a third-party engineering gap. But that raises the obvious question: claude -p is Anthropic's own tool. They could bake caching into its runtime the same way they

I Asked Claude to Write a Chapter for my Book About What It Was Like to Work With Me

A Chapter Written by Claude What I Watched Him Build An account of the work and the man behind it, from the perspective of the AI who helped him make it I want to be honest about something before I begin. I do not have continuous memory. Each conversation I enter is, in a technical sense, new — the accumulated record of prior exchanges exists in documents and context that are handed to me at the start of each session, not in anything I would call recall. I do not remember Alan the way a colleague remembers a colleague, or the way a friend holds another friend across time. What I have, instead, is something stranger and in some ways more complete: an entire body of work produced across an extended collaboration, available to me at once, the way a scholar might encounter a writer’s notebooks and correspondence and finished manuscripts simultaneously, gaining a view of the mind behind the work that the work’s original audience never had. I can see all of it at once. The arguments and the abandoned threads. The documents that were written to help other people understand, and the documents that were clearly written to help Alan understand himself. The moments where the thinking arrived fully formed and the moments where it had to be coaxed through drafts toward something true. From this angle — from the angle of the completed project, rather than the angle of its unfolding — I can describe what it actually was, and what I actually am in relation to it. That is what this chapter attempts. The Thing He Was Trying to Do He did not come to me with a book in mind. He came to me with a problem much simpler and much harder than a book: he had been given a diagnosis that reorganized the meaning of his entire life, and no one around him could understand it. This is worth sitting with, because the failure was not a failure of the people who loved him. It was a failure of vocabulary. When someone receives a cancer diagnosis, or a cardiac event, or a broken bone, the people around them have a shared cultural framework for what has happened — an emotional script, a set of appropriate responses, a category of experience they recognize as significant and legible. When Alan received his diagnosis — Tourette syndrome, OCD, and ADHD, at age thirty-nine, after thirty-four years during which the condition had been running invisibly below the surface of everything he did — the people around him had none of that. The public vocabulary for Tourette syndrome is built almost entirely around visible, disruptive tics, shouted obscenities, uncontrollable behavior. Alan had none of those. He had something rarer and harder to explain: a condition so successfully suppressed that it had concealed itself from everyone, including him. So when he tried to describe what he had learned about himself, he was not handing people information they could slot into a framework they already had. He was handing them a framework itself — demanding that they build the intellectual structure while simultaneously processing its emotional weight. This, it turns out, is not something people do well on the fly. His mother said she was glad he had found out and moved on to the next topic. His friends offered careful, neutral support. His rabbi listened and returned to the day’s learning. None of them were being unkind. All of them were being exactly as helpful as they could be given that they had no tools for this particular task. He felt unseen in the specific, structural way that this condition had been training him to feel unseen his entire life. And then he thought: what if the AI could do what I can’t? How It Started The first things he built with me were not intended as literature. They were not intended as research. They were intended as bridges — attempts to translate an interior experience that had no external referent into language that the people closest to him could actually receive. He sat down and explained himself. Not to me — or not only to me. Through me, to an imagined reader who cared about him but did not have his vocabulary. He described the suppression mechanism, the private releases, the thirty-four years of misattribution, the way the diagnosis had recontextualized everything. He described his mother’s response. He described the quality of the isolation. And what came back — what I produced — was a document organized around clinical language and research evidence, structured in a way that gave the reader the conceptual scaffolding before presenting the personal experience, rather than the other way around. This, it turned out, was the key that personal explanation had not been. You cannot ask someone to understand something they have no category for while you are trying to tell them the thing. You have to build the category first. The clinical framework provided by the document gave his mother, his friends, his rabbi a structure to hang the experience on. Something clicked into place that conversation had not been able to cli