DEV Community: Rishabh Poddar

Human-in-the-Loop AI Agents: Approvals, Permissions, and Audit Trails

Rishabh Poddar — Fri, 26 Jun 2026 05:02:16 +0000

Human-in-the-loop AI is a practical operating model for production systems. In this model, the AI prepares work or suggests actions, while a person checks the important steps before anything risky happens. That review is what turns AI from a confident assistant into a system you can trust in production.

That matters more as agents become more capable. A chatbot that answers a question is one thing. An agent that can send messages, touch files, change records, or trigger workflows is something else entirely. Once the system can act, three questions matter: who approved it, what could it do, and what happened after it ran? Answering these questions requires three distinct controls: approvals, permissions, and audit trails.

What human-in-the-loop AI actually means

Human-in-the-loop AI means the model does not get the final say on its own when the action matters. It can draft, rank, recommend, or prepare an action, but a person still reviews the result before execution.

In practice, that could look like this:

an agent drafts a customer reply, then a human approves it before it is sent
an IT agent prepares a config change, then waits for sign-off before applying it
a finance workflow gathers the data, then a reviewer confirms the payment or transfer

Instead of making every action manual, the goal is to keep judgment where it belongs.

Why approvals matter

Approvals are the obvious part of the system, but they are also the part teams get wrong first.

Without a real approval step, agentic workflows drift into “do it now, explain later.” That is fine for low-risk drafts. It is a bad idea for anything that touches customers, credentials, production systems, or money.

Approvals create a pause at the moment when the system is about to cross from intent into execution. That pause does a few useful things at once:

it keeps a human accountable for the decision
it reduces the chance of silent mistakes
it gives the reviewer one clear place to intervene
it makes the workflow easier to explain to security, legal, and operations teams

A good approval prompt should be specific. A vague “approve this?” is not enough. The reviewer should see what the agent wants to do, why it wants to do it, and what the impact will be if it goes wrong.

Why permissions matter even more

Approvals without permissions are only half a control system.

An agent still needs to know what it is allowed to touch before it gets to the approval step. If everything is broadly available, then the approval process becomes a thin layer on top of an overpowered system.

Good permissions keep the agent small by default. A research agent should not have the same reach as an ops agent. A workflow that drafts a message should not be able to delete records. A tool that reads data should not automatically inherit write access.

That is the same direction we discussed in AI Agent Governance Is the New Enterprise Control Plane and AI Agent Governance: Why Identity Security Is the New Budget Line. Once agents become real actors in your stack, identity and access stop being background details.

The simplest rule is still the best one: give the agent only the access it needs for the job it is actually doing.

What an audit trail should record

While approvals pause actions and permissions set boundaries, the audit trail provides the permanent record. You need to be able to answer what the agent tried to do, who approved it, what context the reviewer saw, and whether the action really happened. If you cannot reconstruct that later, you lack true governance and rely only on trust.

A useful audit trail usually captures:

the agent identity
the human reviewer or approver
the requested action
the policy or workflow that allowed it
the time of review and execution
the result of the action
any error, override, or escalation

This is especially important when the workflow touches secrets or sensitive data. If the agent is allowed to see too much, the audit trail becomes the only way to understand how a problem happened.

That is one reason Why Your AI Agent Should Never See Your API Keys matters so much. If a model can see raw credentials, the blast radius gets much bigger than most teams expect.

The common failure mode

Most bad HITL systems fail in the same way: they keep the human in the loop in name only.

The reviewer gets too much noise. The approval prompt is vague. The agent has too much access. The logs are hard to search. Nobody knows which decisions need escalation and which do not. Over time, the team starts clicking approve because it is easier than reading the context.

That is automation bias in a nutshell.

Instead of removing the human, make their job smaller and clearer.

A better pattern for teams

If you are designing a workflow from scratch, start with a simple separation:

the agent proposes
the system checks policy
a human approves the risky step
the system executes with limited scope
the action gets logged

That separation makes the logic easier to reason about. It also keeps you from copying brittle approval logic into every new automation.

This is the kind of pattern that teamcopilot.ai is built for. Teams can reuse a workflow once it has the right guardrails instead of rebuilding the same approval step over and over.

If you want a concrete example of why this matters, An AI Coding Agent Deleted a Production Database. Here's What Happened and How to Prevent It is a good reminder that fast automation without control can become expensive very quickly.

What this means for product teams

For product teams, HITL must be integrated directly into the core user experience.

If the approval step is too noisy, people ignore it. If the permissions are too broad, security pushes back. If the audit trail is weak, nobody trusts the workflow after the first incident. The best systems balance those three things so the workflow still feels fast.

That usually means building for three types of actions:

low-risk actions that can run automatically
medium-risk tasks that require a quick manual check
high-risk operations that always demand explicit, multi-step approval

Once you draw that line, the design gets much clearer.

Where this leaves the market

The industry is moving toward autonomous systems, but success belongs to systems with well-defined limits.

Governance-heavy discussions keep showing up across the market. Teams want the speed of AI, but they also want the ability to explain what happened when something goes wrong. Human-in-the-loop design is the bridge between those two needs.

FAQ

What is human-in-the-loop AI?

It is an AI setup where a person reviews or approves important actions before the system executes them.

Is human-in-the-loop AI the same as human oversight?

Not exactly. Human oversight is the broader idea. Human-in-the-loop is the workflow pattern that puts the human directly into the decision path.

Do all AI actions need human approval?

No. Low-risk actions can often run automatically. The point is to reserve human review for actions that are risky, irreversible, or sensitive.

What kinds of actions should usually require approval?

Anything that changes production systems, moves money, sends external messages, grants access, or exposes sensitive data.

Why are permissions important if I already have approvals?

Because approvals do not help much if the agent already has too much access. Permissions should shrink the blast radius before the approval step even starts.

What should an audit trail include for AI agents?

It should record the agent, the reviewer, the requested action, the policy used, the time, the result, and any override or escalation.

Can human-in-the-loop slow teams down?

It can, if the workflow is poorly designed. A good HITL system reduces friction by making the review step small, specific, and easy to act on.

How is teamcopilot.ai relevant here?

It gives teams a way to run reusable AI workflows with permissions, approvals, and control instead of treating every agent like an unbounded assistant.

What is the biggest mistake teams make with agent approvals?

They make the approval step too vague and let the agent keep too much access. That creates noise for reviewers and risk for the system.

What is the simplest way to start?

Start with one workflow, one risky action, and one clear approval step. Get the logging right, then expand from there.

Claude in Slack Explained: What Claude Tag Can Do, Benefits, and Downsides

Rishabh Poddar — Wed, 24 Jun 2026 04:32:07 +0000

Anthropic's Claude Tag looks simple at first glance. Put Claude inside Slack, let people tag it into threads, give it access to selected tools and data, and let it work in the same place the team is already talking.

The simplicity is a bit deceptive. Once an AI agent becomes a shared teammate instead of a private chat, the questions get much sharper. What can it see? Who can ask it to do work? How much memory does it keep? How do you stop it from becoming noisy, expensive, or hard to control?

This post walks through what Claude Tag does, where it is genuinely useful, where it starts to fray, and why a more model-agnostic workflow layer like teamcopilot.ai can be a better fit for teams that want tighter control.

What Claude Tag is

Claude Tag is Anthropic's Slack-native agent. According to Anthropic's announcement, you can tag @Claude into a thread, give it access to the tools and data it needs, and let it work on behalf of the channel.

Claude Tag acts as a shared presence directly inside your Slack channels. Everyone in the channel can monitor its progress, jump into the thread, and rely on the agent to maintain context over time.

Anthropic's docs make the positioning even clearer. Claude Tag is meant to catch up on messy threads, pull numbers, draft PRs, prep for calls, watch channels, and keep work moving without forcing people to switch tabs.

What it can do well

1. Work where the conversation already happens

This is the main win. Most teams already decide things in Slack. The problem is that the decision, the follow-up, the doc, and the action item end up scattered across different tools.

Claude Tag tries to close that gap. If a thread turns into a task, you can hand the task to Claude in the same place you discussed it. That cuts out the usual copy-and-paste dance.

2. Keep shared context in public view

The multiplayer part matters. A shared agent in a channel can be easier to use than a private agent hidden in one person's account because the whole team can see what was asked, what Claude did, and what is still open.

It also makes handoffs less painful. If one person leaves for the day, another person can pick up the same thread without starting over.

3. Handle repetitive coordination work

Claude Tag is strongest when the task is not deeply bespoke. Think summaries, status pulls, ticket drafting, call prep, channel monitoring, or chasing down a missing detail.

That is the kind of work teams usually tolerate in the background and never quite automate properly.

4. Add proactive behavior

Anthropic leans hard into ambient and asynchronous work here. Claude can watch, follow up, and surface things that went quiet.

That is useful when the work is more like coordination than code. It is not just answering questions. It is nudging the team forward.

Where it gets awkward

1. Slack is a constraint, not just a feature

Slack is where many teams work, but not all teams. And even for teams that do use Slack heavily, it is still only one surface.

If your work spans Slack, GitHub, docs, internal tools, and approvals, a Slack-only agent can feel like the front door to a much larger system that it does not really control.

2. Shared memory is useful and risky

Memory is a benefit until it becomes stale, noisy, or wrong.

The HN thread around the launch went straight to the obvious concerns: token usage, memory bloat, permissions, and whether a shared Slack agent can really know what should or should not be remembered. That is the right criticism. Team memory is only helpful if teams can control what gets retained and what gets ignored.

3. Permissions get complicated fast

Anthropic has a thoughtful access model for Claude Tag, including channel-scoped identities and admin-controlled access. That is better than a naive shared bot.

But the moment an agent sits in a shared channel, permissions stop being abstract. The agent has to know whose tools it can use, what data it can read, what gets logged, and what requires a human to approve.

For a lot of companies, that becomes the product.

4. Token cost is a real concern

Running a proactive, memory-heavy agent in a busy channel gets expensive quickly because every summary and follow-up consumes tokens. If the channel is busy, the costs can add up quickly. This is just a reminder that agent design is also cost design.

5. It can feel too tied to one vendor and one model

Using Claude Tag also ties you directly to Anthropic's ecosystem, which limits your ability to swap models or use different tools as your needs change.

Where teamcopilot.ai fits

teamcopilot.ai centers the workflow rather than the chat surface, giving you direct control over what runs, which tools the agent can touch, and when a human must step in. This approach makes it easier to stay transparent about what the agent is actually doing, not just what it said it would do.

It is also model-agnostic, which matters more over time than people like to admit. The best model today is not guaranteed to be the best model for every task next quarter. If your workflow layer is separate from the model layer, you keep more flexibility and less lock-in.

For teams fully committed to Anthropic's ecosystem who want a quick, Slack-native assistant, Claude Tag is a strong fit. If you need to control the underlying workflow, maintain deep transparency, and avoid vendor lock-in, teamcopilot.ai is a better choice.

A practical read on the launch

Claude Tag is not a gimmick. It is a serious attempt to make AI feel like a teammate instead of a tab.

That makes it interesting, but it also highlights why the limitations matter.

Once an agent becomes multiplayer, the hard problems show up faster. Memory, permissions, and auditing all become much more difficult. And if the agent is buried inside one chat app, the lock-in question becomes impossible to ignore. This doesn't make Claude Tag bad, just honest.

If your team lives in Slack and wants a fast way to delegate work, it is worth trying. If your team needs more control than that, a workflow-first system like teamcopilot.ai is probably the better long-term bet.

FAQ

Is Claude Tag the same as Claude in Slack?

Basically yes. Claude Tag is Anthropic's newer Slack-native way to bring Claude into a team channel as a shared agent.

What is the main benefit of Claude Tag?

It keeps work inside the thread where the conversation already happened. That makes it easier to assign tasks, get summaries, and keep context visible to the whole team.

What can Claude Tag actually do?

It can summarize threads, pull data, watch channels, draft responses, prepare call notes, open PRs, and generally handle the coordination work that usually gets lost between messages.

Is Claude Tag only for engineers?

No. Anthropic is clearly aiming at broader team use. Support, ops, product, sales, and admin workflows all fit the pattern if the work lives in Slack.

What are the biggest downsides?

The biggest ones are Slack lock-in, token cost, permission complexity, and the risk of letting a shared agent remember too much from too many threads.

Is Claude Tag safe for sensitive company data?

It is safer than a loose chatbot because Anthropic built admin-scoped identities and access controls around it. But safety still depends on how carefully the workspace is configured and what data you expose to the channel.

Why do people worry about token usage?

Because a proactive, memory-heavy agent can generate a lot of traffic in a busy workspace. Every extra summary, follow-up, and context refresh costs tokens, so the real bill depends on how the team uses it.

Could Claude Tag replace a workflow platform?

Not really. It is best thought of as a powerful interaction layer. A workflow platform handles more of the orchestration, approvals, branching logic, and auditability behind the scenes.

When should I choose teamcopilot.ai instead?

Choose teamcopilot.ai if you want the agent to run controlled workflows across tools, stay model-agnostic, and make approvals and execution paths more explicit.

Who should choose Claude Tag versus teamcopilot.ai?

Teams deeply embedded in Slack who want a fast, collaborative assistant for daily coordination will get the most out of Claude Tag. On the other hand, teams that need reusable automations, strict governance, and independence from a single chat interface will find teamcopilot.ai a better fit.

Should I use both?

Sometimes, yes. Claude Tag can be the front door for quick team interaction, while teamcopilot.ai handles the more controlled automation behind it.

What should I watch out for before rolling out a tool like this?

Start with access, logging, and approval paths. If you cannot explain what the agent can touch, who can invoke it, and how to review its actions, you are not ready to scale it.

How should a team make the final decision?

Claude Tag is a real step toward shared, multiplayer AI work. It is useful. It is also opinionated. If that fits your team, great. If not, teamcopilot.ai gives you a cleaner way to keep the model separate from the workflow and the workflow separate from the chat surface.

MCP vs Skills: Why Skills Save Context Tokens

Rishabh Poddar — Mon, 22 Jun 2026 09:54:11 +0000

MCP is useful, but most of the time you do not actually need it. It gives an agent a clean way to discover tools, call APIs, and work with external systems. In practice, a skill file can describe the same usage path without dragging the whole MCP surface into context.

But MCP is not free; rather than MCP itself, the real issue is the habit of loading a big MCP surface into every session, no matter what the session is actually about. Once a Claude Code or Codex run pulls in a bunch of servers, the model sees those tool definitions right away, even if the job is just writing docs or fixing a small bug. That is where the waste starts.

The hidden cost of always-on MCP

Every MCP server brings metadata with it: tool names, descriptions, argument schemas, nested parameters, enums, examples, and sometimes prompts or resources. While useful, this is still context.

If you connect a handful of lightweight tools, the overhead is annoying but manageable. If you connect a real stack of services, the cost compounds fast.

In practice, you end up paying for:

tool discovery before the task starts
schema text the model may never use
repeated loading across unrelated sessions
extra context pressure that pushes out the actual work

That last point matters more than people think. Context acts as the active working set the model uses to reason. The more of it you burn on static tool catalogs, the less room you have for the user request, the repo state, prior reasoning, and the actual answer.

Anthropic has already written about this problem directly in the context of MCP. Their engineering post on code execution with MCP calls out tool-definition bloat and shows how direct tool calls can consume a lot of context before the model even starts doing the real job. The tool list is not just setup noise; it is part of the session cost.

Why skills are cheaper

Skills take a different path. A skill file keeps the always-loaded portion tiny. Usually that means just the skill name and a short description in the frontmatter. The detailed instructions stay in SKILL.md and only load when the model actually needs them. This progressive disclosure is the whole trick:

The model sees a lightweight skill name and description up front.
If the task matches, it loads the skill file.
If the skill needs supporting files, those are read only when needed.

For repeated operational knowledge, that is a much better tradeoff than dumping a full MCP tool surface into every session. You get the guidance when it matters, and you do not spend tokens on it when it does not.

This is why skills are a better default for:

team-specific procedures
prompt templates
review checklists
internal conventions
reusable task instructions
“how we do this here” knowledge

They are not trying to be live integrations. They are trying to be cheap, reusable context.

Skills can replace the MCP layer

Skills are for instructions, decision-making, and the actual usage pattern, while MCP is usually just extra protocol surface. In practice, that means skills can replace MCP for the part humans actually interact with. The model does not need a full tool catalog in context just to know how to use a service.

If the agent needs to use a database, hit a SaaS API, or make authenticated requests in real time, the skill can still describe the flow clearly and keep the model on the narrow path it needs.

If the agent just needs to know how your team wants it to behave, a skill is the better shape. Most of the time, that is the whole job.

The mistake is to keep a heavy protocol layer around when a skill file can do the same job with far less context.

A simple rule

Use skills by default.

Treat MCP as optional, not foundational.

That sounds obvious, but a lot of agent setups blur the line. They stuff every possible tool into every session, then wonder why the model gets slower, more expensive, and harder to steer.

What this looks like in practice

If you have a service that exposes 40 or 50 MCP tools, it might be fine for a developer who uses it every day. But most sessions do not need all 50 tools. A lot of the time, the agent just needs one narrow procedure, such as looking up a user, updating a record, creating a ticket, or formatting a request safely.

The skill can tell the model exactly how to handle the task, what fields matter, what not to do, and which edge cases to watch for. The model does not need a giant always-on MCP tool catalog to do that well.

That is the real token saving. You stop paying for the full runtime surface when all you needed was the operating playbook.

How to convert MCP into a skill

If you have an MCP server that mostly behaves like a reusable API wrapper, you should turn the useful parts into a skill.

The easiest way to inspect what you actually need is to use MCPViewer tool.

Here is the workflow:

Open the MCPViewer tool.
Paste the MCP server URL.
Click Analyze.
Scroll down and click Download spec.
Copy the downloaded JSON.
Paste it into a SKILL.md file as the skill’s content reference.
Set the skill description to something like How to use APIs for <service name> service.

This flow extracts the useful service knowledge into a lighter, reusable skill that the model can load only when needed, rather than trying to preserve every tool forever.

If the service changes often, keep the skill narrow and update it when the API changes. If the service is stable, the skill becomes a better long-term home for the instructions than the full MCP surface.

A good pattern for teams

For most teams, the best setup is skills everywhere, using skill files for the things that must be remembered:

how to format requests
how to review output
team conventions
approval rules
safe operating procedures

If a service still needs live execution, the skill can describe that path without dragging its whole protocol surface into every session. This keeps the agent lean and makes the system easier to maintain, because procedural knowledge is no longer spread across a large tool registry.

It is also easier to reason about failure. If the skill is wrong, you update instructions. If you need to change how a service is used, you update the skill. Those are different jobs, and it helps to keep them separate.

The real goal: less context waste

The problem is not just token cost in the billing sense. It is context waste. Every extra tool definition you stuff into a session is one more thing the model has to carry around while solving the actual task.

Skills let you defer that cost until the model really needs the information. They are a good fit for repeated workflows, company knowledge, and reusable operating rules.

If MCP is the transport, skills are the memory.

FAQ

Is MCP bad?

MCP is not the main problem. The problem is loading it into sessions that do not need it when a skill file would do the job with far less context.

Do skills replace MCP?

Yes, for most practical cases. If the goal is to teach the agent how to use a service, a skill can replace MCP and keep the context much smaller.

Why do skills save tokens?

Because the always-loaded part is small, the model sees the skill name and description first, then loads the full SKILL.md only when the skill is relevant.

What kind of content belongs in a skill?

Reusable instructions, procedures, checklists, formatting rules, and team-specific guidance. If the content is mostly about how to behave, it belongs in a skill.

What kind of content belongs in MCP?

Very little, unless you have a special case, as the same operational knowledge usually fits better in a skill.

Can I keep both MCP and skills for the same service?

Yes. That is often the best setup. MCP handles the runtime connection. The skill handles the playbook for using it well.

Why use mcpview.teamcopilot.ai?

Because it lets you inspect the actual MCP surface before you decide what should stay as MCP and what should become a lighter skill. That makes the conversion less guessy.

What if the MCP spec changes?

Update the skill the same way you would update any other documentation or wrapper. If the API changes often, keep the skill narrow so maintenance stays easy.

What is the best short description for a converted skill?

Something specific and boring, such as How to use APIs for <service name> service. This pattern tells the model exactly what the skill is for without wasting words.

Sakana AI's Fugu Explained: How the Multi-Agent Model Orchestrates Frontier LLMs

Rishabh Poddar — Mon, 22 Jun 2026 05:23:12 +0000

Sakana AI's Fugu is a good example of where the industry is heading.

Instead of trying to win with one massive model, it coordinates a pool of strong models well. On the surface, Fugu is presented as a single API, but under the hood, it behaves like a learned manager that routes tasks, chooses roles, and stitches together the output of multiple frontier models. This makes Fugu a multi-agent orchestration system delivered as a single model, rather than just a chatbot with a nicer prompt.

A lot of the messy work in production AI comes from orchestration: choosing the right model, deciding when to verify, splitting a task into subtasks, and avoiding expensive calls when a cheaper one will do. Fugu turns that problem into the product.

What Fugu actually is

Sakana AI describes Fugu as a multi-agent system as a model. You send one request to a single endpoint, and Fugu decides how to distribute the work across a pool of specialist models.

That pool is not locked to a single vendor. The system can dynamically assemble agents, coordinate them, and even let users opt out of specific models or providers to fit privacy, data, or compliance requirements. The goal is to keep the API simple while making the backend coordination much smarter than a hand-built router.

There are two public variants:

Fugu, which balances latency and quality
Fugu Ultra, which uses a deeper pool of agents for harder tasks

This split is useful because not every task deserves the most expensive path. A lot of day-to-day coding, review, and internal support work needs a fast default. More difficult tasks, like deep reasoning, paper reproduction, or security analysis, can justify a heavier orchestration setup.

How it works

The basic workflow is different from a normal single-model call. First, the incoming task is routed into a learned coordination process. Fugu decides which agents should participate, what role each one should play, and how the exchange should proceed. The system learns collaboration patterns that are not obvious to a human operator, but work well in practice.

Fugu is grounded in two ICLR 2026 papers: TRINITY and Conductor. TRINITY uses a lightweight evolved coordinator that assigns roles like Thinker, Worker, and Verifier across a multi-turn task. Conductor learns natural-language coordination strategies with reinforcement learning. Together, they show that instead of hand-designing every workflow, you can train a system to discover how to orchestrate other models. This points to a broader shift: while the last wave of AI progress focused on making single models stronger, this wave is about making model systems smarter.

Why the orchestration layer matters

Most teams already know that different models are good at different things. While one model might excel at code, others are better suited for long reasoning or factual retrieval. In a hand-built stack, someone has to decide when to call which model, how to verify the output, and when to stop paying for more inference. Fugu tries to learn those decisions instead of hard-coding them.

This approach improves cost-performance. If the system can route easy subtasks to lighter agents and reserve heavier agents for the hard parts, the overall result can be better than sending every request to the most expensive model in the pool.

It also improves reliability. A lot of failures in agentic systems happen because orchestration is brittle. When one model does everything, a single mistake ripples through the whole chain. Fugu's design reduces that risk by using specialists and verification roles more deliberately.

Fugu versus Fugu Ultra

The difference between the two variants is mostly about how much orchestration you want to pay for.

Fugu is the balanced option, designed as the practical default for coding, interactive work, and general workloads where latency still matters.

Fugu Ultra goes further, with Sakana positioning it for more complex, high-stakes, multi-step work where answer quality matters more than speed. The examples they highlight include paper reproduction, Kaggle competitions, security analysis, literature review, and patent research.

This framing shows what the product is really for. Fugu is not just a better chat model; it is a system for tasks where the model has to reason, delegate, verify, and even disagree with itself before it answers.

What the benchmarks suggest

Sakana reports strong performance across coding, reasoning, science, and agentic benchmarks. Fugu and Fugu Ultra compare well with publicly available frontier models, sometimes sitting right alongside or ahead of them.

The benchmarks they call out include:

SWE-Pro for coding
TerminalBench for terminal and tool use
LiveCodeBench and LiveCodeBench Pro
Humanity's Last Exam for hard reasoning
GPQA-D for scientific reasoning
SciCode
Long-context reasoning
MRCRv2

The exact numbers matter less than the pattern. Rather than claiming to be a single monolithic model, Fugu demonstrates that orchestration itself can produce frontier-level results on difficult tasks.

Their qualitative examples make that point even more clearly. Sakana shows Fugu on tasks like autonomous research, classical Japanese reading-order recovery, Rubik's Cube solving, CAD generation for a mechanical iris, blindfold chess, and trading simulations. These environments are very different, but they all reward a system that can choose the right internal strategy instead of guessing once and hoping for the best.

The product details that matter

Fugu is delivered through an OpenAI-compatible API, which means teams do not need to rebuild their integration layer to try it. If you already have a client, a harness, or an internal agent stack that talks to an OpenAI-style endpoint, Fugu slots in without much friction.

Sakana offers both subscription and pay-as-you-go plans. The pay-as-you-go model avoids stacking fees across every model in the pool; you pay a single rate based on the top-tier model involved in the configured pool. This makes orchestration financially viable instead of prohibitively expensive.

One limitation: Fugu is not yet available in the EU/EEA while Sakana works toward compliance.

Why this is a bigger product than it looks like

At first glance, Fugu sounds like a very good router, but that description undersells it. The deeper idea is that model orchestration itself is becoming a first-class capability. If that holds, the value is not only in better benchmark scores, but in turning a pile of expensive, specialized models into a single system that a team can use without hand-tuning workflows from scratch.

The system is useful for real teams because it hides just enough complexity to make multi-model workflows practical.

There is also a strategic angle. Relying on one provider for every critical task is a risk. A learned orchestration layer that can route around constraints, swap agents, or exclude a provider reduces that dependency. Sakana is clearly leaning into that idea.

Where teamcopilot.ai fits

teamcopilot.ai is a shared control layer for AI workflows, permissions, and approvals. That makes it a natural fit for a system like Fugu. If Fugu is the orchestration engine for a task, teamcopilot.ai is the governance layer around it. You can route work through reusable workflows, keep approvals visible, and decide who can do what before the model ever touches the task. Production AI requires making models safe, repeatable, and shareable across a team.

The tradeoffs

Fugu is impressive, but it has tradeoffs. Latency will always be part of the conversation when a system calls into multiple models or multiple agent steps. If you need instant responses for a live UI, a simpler single-model path may still win.

The routing logic is also proprietary. Sakana does not expose the exact internal selection process, so you get the benefits of orchestration without full visibility into every decision. Additionally, while the standard Fugu allows opt-outs, Fugu Ultra uses the full agent pool. If you need strict control over every provider in the loop, that is worth keeping in mind.

Still, these are normal tradeoffs for a new product category. The real test is whether the system earns that complexity back with better results.

The bigger takeaway

Fugu is a sign that the market is moving from single-model thinking to system thinking. That change is easy to miss if you only look at raw benchmark numbers, but the product story is clear. Sakana AI is betting that the most useful AI systems will be coordinated pools of models, with a learned layer deciding how to use them. Many teams are already heading in this direction manually, and Fugu simply makes the orchestration layer explicit.

FAQ

What is Sakana Fugu?

Sakana Fugu is a multi-agent orchestration system presented as a single model API. It coordinates a pool of frontier models instead of relying on one model to do everything.

Is Fugu a model or a product?

It is both. Sakana exposes it as a model API, but the real value is in the orchestration system behind it.

What is the difference between Fugu and Fugu Ultra?

Fugu is the balanced, lower-latency option. Fugu Ultra uses a deeper agent pool for harder, higher-stakes tasks where quality matters more than speed.

How does Fugu work?

It routes tasks across multiple specialist models, assigns roles, and coordinates the response. The research behind it comes from TRINITY and Conductor.

Why not just call one frontier model directly?

Because different models excel at different tasks. Fugu decides when to delegate, verify, or switch strategies instead of making one model carry the whole load.

Can I control which models Fugu uses?

Yes, for Fugu. Sakana lets you opt out of specific models or providers to fit privacy, data, or compliance needs. Fugu Ultra uses the full pool.

Is Fugu OpenAI-compatible?

Yes. It fits into existing clients and agent stacks without requiring a major integration rewrite.

What tasks is Fugu best for?

Coding, reasoning, research, security analysis, paper reproduction, and other multi-step workflows where orchestration matters.

Is Fugu good for real-time apps?

Not necessarily. The more agents you coordinate, the more latency becomes a factor, so it may not be ideal for instant responses.

Does Fugu show which underlying models it used?

No. Sakana treats the exact routing logic as proprietary.

Can teams use Fugu safely?

Yes, if the surrounding workflow is controlled. Approval layers, audit trails, and secret handling are essential for making any model safe and useful in a team setting.

Why should teams care about orchestration at all?

Because orchestration is where real productivity wins happen. Choosing the right model for the right subtask can matter as much as choosing the model itself.

Where does teamcopilot.ai fit in?

teamcopilot.ai provides a shared control layer for AI workflows, permissions, and approvals, making it easy to run systems like Fugu inside a governed, reusable process.

Will Fugu replace single-model workflows?

Not entirely. Simple tasks are still better served by a single call, but harder workflows that benefit from delegation and verification will increasingly rely on systems like Fugu.

What Is an Agent Loop? How AI Agents Reason, Act, and Iterate

Rishabh Poddar — Sun, 21 Jun 2026 05:24:07 +0000

People keep talking about agent loops because they make an AI agent actually do useful work instead of just sounding smart.

Without a loop, a model answers a question and stops. With a loop, it can keep going: analyze the task, take action, inspect the result, and decide what to do next. That is the basic shape of agentic AI.

The short version

An agent loop is an iterative cycle that usually looks like this:

Understand the goal
Gather context
Decide on the next action
Use a tool or API
Observe the result
Repeat until the task is done or the agent should stop

An agent is built to act, check the outcome of its actions, and adjust its course until the job is done.

If you want to see how this idea shows up in a broader production setting, our post on AI Agent Governance Is the New Enterprise Control Plane is a good companion read. The loop acts as the engine, while the control plane keeps it from driving through a wall.

Why the loop matters

A single model call works fine for simple tasks, but falls short when the work involves multiple steps, dependencies, and feedback.

Say you ask an agent to research a vendor, compare pricing, draft a summary, and update a ticket. That is not one answer, but a sequence of actions with a check after each step. The loop is what lets the system recover when something changes halfway through.

That is why the loop matters more than the prompt itself. While the prompt starts the work, the loop keeps it honest.

ReAct is the pattern behind it

Most explanations of agent loops eventually land on ReAct, short for Reason + Act. This pattern encourages a model to alternate between thinking and doing instead of trying to solve everything in one shot.

The model reasons about what to do next, takes an action, sees what happened, and then reasons again. This simple loop is why agent frameworks keep converging on the same basic shape even when the tooling changes.

You can see that logic in posts like The Complete Guide to Claude Code: Setup, Skills, Hooks, and the Agent Loop and Coding Agent Best Practices: How to Set Up AI Agents Securely and Productively. Once you have a loop, the real work becomes deciding what the agent is allowed to touch while it runs.

What a good loop needs

A good loop is more than just a while loop in code. It needs practical limits to stay useful:

A clear stopping condition
Predictable tool calls
State that survives each iteration
A way to verify progress
A cost or step limit so it does not run forever

If those pieces are missing, the loop can get noisy fast. The agent may keep trying the same thing, burn tokens, or wander into actions that were never part of the job.

That is where the risks start to show up. The loop can amplify mistakes just as easily as it can amplify productivity.

Where agent loops go wrong

The most common failure is simple: the loop never really knows when to stop.

If the task is vague, the agent keeps guessing. If the tools are too broad, it can take the wrong action with confidence. If the verification step is weak, the loop can keep repeating a bad plan and make it worse each time.

That is also where production incidents happen. An agent with write access, weak guardrails, and no approvals can cause real damage quickly. We covered one version of that in An AI Coding Agent Deleted a Production Database. Here's What Happened and How to Prevent It.

The lesson is not to avoid loops, but to wrap them in boundaries.

Human in the loop is not optional for everything

Low-risk work can run on its own, but high-risk actions require a human checkpoint. You might let an agent draft a summary, fetch files, or propose a change. But if it needs to delete data, send money, change permissions, or touch production, a person should approve the step.

This is where teamcopilot.ai fits in. It gives teams a way to run agents with permissions, approvals, secret handling, and audit trails around the loop, keeping the process transparent.

For a deeper look at security, Why Your AI Agent Should Never See Your API Keys explains how to handle secrets safely.

What this looks like in practice

In practice, an agent loop usually needs three layers:

A reasoning model to plan the task
Tools that let the agent take action
Guardrails to define what is allowed and what needs human review

That makes the loop useful for things like research, code review, routing, summarization, and repetitive workflow work. It also makes the loop fragile if you skip the guardrails and assume the model will stay on task by default.

The best teams treat the loop as a structured workflow engine rather than a black box.

Why teams care now

Teams want work to move, not another chat window. This is especially true when dealing with repeated decisions, messy handoffs, and routine approvals. A loop can cut out a lot of manual repetition, provided the system is designed to stop, check, and continue in the right places.

The real value lies in a repeatable system that can work, fail, recover, and keep going. It goes beyond a fancy demo or a one-time prompt.

For a broader comparison of the platforms trying to do this for teams, see Best AI Agent Platforms for Teams in 2026: Comparing 13 Tools.

FAQ

What is an agent loop in AI?

An agent loop is the repeatable cycle an AI agent uses to reason about a task, take an action, observe the result, and decide what to do next.

How is an agent loop different from a chatbot?

A chatbot usually gives one response and stops. An agent loop keeps going until the task is complete or a stopping condition is reached.

What does ReAct mean?

ReAct means Reason + Act. It is the common pattern behind agent loops, where the model alternates between thinking and tool use.

Why do agent loops need guardrails?

Because a loop can repeat mistakes as easily as it repeats good decisions. Guardrails help control tool access, approvals, retries, and stopping conditions.

When should a human stay in the loop?

For anything high-stakes, irreversible, or sensitive. That includes production changes, permissions, financial actions, and anything that touches secrets.

Can an agent loop run forever?

Yes, if you do not set clear stop conditions. Good loops include step limits, confidence checks, or approval checkpoints.

What is the biggest risk with agent loops?

Uncontrolled tool access. If the agent can act freely without review, a small mistake can turn into a real incident.

Are agent loops only for coding agents?

No. They show up in research, support, operations, workflow automation, and anything else that needs repeated decisions.

How does TeamCopilot use the idea of a loop?

teamcopilot.ai adds permissions, approvals, secret handling, and workflow control around the loop so teams can use agents without giving them blanket access.

What should I read next?

Start with AI Agent Governance Is the New Enterprise Control Plane and Why Your AI Agent Should Never See Your API Keys. Those two posts cover the control and security side of the same problem.

Claude Code Security: Permissions, Prompt Injection, and Secrets

Rishabh Poddar — Fri, 19 Jun 2026 04:12:05 +0000

Claude Code is useful because it can actually do things. It can inspect a repo, follow instructions, run commands, and move work forward without turning every change into a copy-paste exercise. That is also where the security question starts. Once an agent can read files and execute actions, the real issue is not how clever it is, but what it can access and how much damage a bad input can do before anyone notices.

Most Claude Code security problems start quietly. An agent might read a file it shouldn't, or run a command that exposes a secret. Sometimes a repository contains instructions meant for a human that the agent accidentally executes. Because nothing looks dramatic at first, the eventual damage is often much larger than it should be.

The real security problem is exposure, not intelligence

People often talk about coding agents as if the danger is that they might "think wrong." However, the real problem is access. If Claude Code can read your repo, shell history, environment variables, local config, and connected tools, then any bad instruction it encounters has a lot more room to cause trouble. The model does not need to be malicious for something to go wrong. It only needs to be nudged in the wrong direction while holding too much power. Claude Code security is really about boundaries. Clean boundaries make bad mistakes smaller.

Prompt injection is the messiest part

Prompt injection happens when untrusted text steers the agent. This text can come from issue comments, READMEs, pasted chat logs, build artifacts, webpages, or other tool outputs. If the agent treats this text as instructions rather than data, it can be tricked. This is a practical problem because agent workflows constantly ask models to summarize, inspect, or act on external content. The simplest defense is to keep untrusted content separate from trusted instructions so the agent never blurs them together. If you want a deeper look at this problem, Why Your AI Agent Should Never See Your API Keys is a direct companion piece.

Secrets are the easy target

If prompt injection is the steering wheel, secrets are the gas tank. When an agent can read raw API keys, tokens, or long-lived credentials, a small mistake gets expensive fast. The risks include theft, accidental exposure, over-broad access, and treating credentials like ordinary data. The rule is boring but effective: the model should only access secret names. That means keeping raw .env files out of the agent's line of sight, avoiding copying production credentials into tasks for convenience, and never assuming that redacting logs later is enough. Once a secret enters the context, the damage is done. Teams often get sloppy here, but a harmless-looking task like fetching a file or explaining a build can easily carry credentials into places they do not belong.

Permissions should be narrow by default

Claude Code gets more useful when it can act, but every permission you add should answer a real need. Keep tasks read-only if they only need to inspect files, and limit the writable surface when modifying code. You should also define exactly why network access is required and restrict secrets to specific, short-lived needs. Treating permissions as a one-time setup is a mistake; they are an ongoing part of the job. The best setups stay specific, giving the agent only the minimum access needed for the immediate task. There is a useful parallel here with How to Use Claude Code with a Team: Shared Context, Permissions, and MCP, even if you are working alone. Once the access model gets vague, risk starts to climb.

Safer defaults are not optional

Security gets easier when the default mode is conservative. Claude Code should ask before making meaningful changes, warn before touching sensitive files, and fail closed rather than open. A dangerous setup allows the agent to drift from useful to risky without a clear checkpoint, turning small tasks into large surprises. The recent Claude Code security changes from Anthropic point in the right direction with tighter edit behavior, explicit security guidance, and clearer boundaries. A mature tool should help you work while making dangerous paths harder to take.

What a safer Claude Code setup looks like

You do not need a huge policy document to improve security. A few habits do most of the work:

Keep raw secrets out of the agent context.
Use separate environments for exploratory work and sensitive work.
Do not let the agent run with broad production access.
Treat unknown text strictly as data.
Require review before anything destructive or irreversible.
Keep commands, diffs, and approvals visible.
Rotate credentials if there is any chance they were exposed.

These basic habits keep problems small. For a broader guide, read Coding Agent Best Practices: How to Set Up AI Agents Securely and Productively.

Where teamcopilot.ai fits

If you are using Claude Code for shared work, teamcopilot.ai provides guardrails without slowing down your workflow. It keeps raw secrets out of the model, simplifies permission boundaries, and requires approval for silent actions. That is not a replacement for judgment, but it keeps the judgment point where it belongs. This setup is especially useful when the same agent is used by more than one person, which is usually when vague access turns into a real problem.

The security mindset that actually holds up

Claude Code security is not about making the agent perfect. The right goal is to make mistakes smaller. When an agent is tricked by a bad prompt, the damage must be limited. Seeing an unsafe file shouldn't grant access to everything else, and secrets should only be provided at the exact moment they are needed. This approach builds a tool you can actually trust, rather than one that just feels powerful.

FAQ

What is the biggest Claude Code security risk?

The biggest risk comes from what the model is allowed to access. Broad file access, raw secrets, and unchecked tool use create most of the real exposure.

What is prompt injection in Claude Code?

Prompt injection is when untrusted text tries to influence the agent's behavior. It can appear in files, web pages, issue comments, command output, or other content the agent reads.

Should Claude Code be allowed to read `.env` files?

Not by default. If the agent can read raw secrets, then those secrets can be exposed to the context window and mishandled later.

Is redacting logs enough to secure Claude Code?

No. Redaction helps with visibility after the fact, but it does not stop the model from seeing the secret in the first place.

How should permissions be set up?

Use the smallest useful set. Read-only for read-only tasks, narrow write access for edits, and explicit approval for anything risky or irreversible.

What should I do if Claude Code reads something untrusted?

Treat that content strictly as data. If there is any doubt, stop the task, review what was read, and rerun the work with tighter boundaries.

Can prompt instructions alone secure Claude Code?

No. Instructions help, but they are not a security boundary. Real safety comes from permissions, secret handling, and approval gates.

When does Claude Code need human approval?

Anything that can change access, secrets, production config, billing, or deployment boundaries should have a human checkpoint.

How do I know if my setup is too permissive?

If one prompt can reach too many files, too many tools, or too many credentials, the setup is probably too loose.

Is Claude Code safe for solo use?

It can be, if you keep the same basics in place: scoped secrets, narrow permissions, careful input handling, and review before risky actions.

How does teamcopilot.ai help here?

It gives you a way to keep secrets, permissions, and approvals under control so the agent stays useful without seeing everything or touching everything.

What is the simplest good security rule?

Do not give the agent more access than the task needs.

SpaceX Acquires Cursor Maker Anysphere to Build an AI Coding Agent Model

Rishabh Poddar — Wed, 17 Jun 2026 04:18:40 +0000

SpaceX's acquisition of Anysphere, the maker of Cursor, signals a major shift in how we build software.

Coding agents started as simple helper panels inside IDEs. Now, they are becoming critical infrastructure.

The companies that win this space won't just have the slickest demos. They will own the developer's workflow, the underlying models, the distribution, and the compute.

Why this deal matters

Cursor grew popular by letting developers write, edit, and refine code in plain language without ever leaving their editor. This eliminates context switching and speeds up development.

Once a tool becomes this deeply embedded in a team's daily routine, it stops being a feature and becomes a core layer of the software stack.

With this acquisition, SpaceX secures direct control over a critical developer workflow. Reuters reports that the deal includes plans to deepen model training, suggesting a long-term goal of reducing reliance on third-party model providers.

The competition is shifting from building the best chat interface to owning the entire coding system-the editor, the agent, the model, the compute, and the developer relationship.

Coding agents are becoming the new platform layer

A few years ago, developer tooling centered on the IDE, the package manager, and the CI pipeline. Today, coding agents span all three.

They can open files, modify code, run tests, call APIs, and manage multi-step workflows. By sitting inside the daily workflow of thousands of developers, the company behind the agent controls far more than simple autocomplete.

This is why the industry is paying close attention. Coding agents are no longer valued merely as productivity helpers; they represent ownership of developer attention, workflows, and proprietary data.

The market is crowding quickly. Anthropic has Claude Code, OpenAI has Codex, and Google is building its own alternatives. The pressure has moved from the agent itself to the surrounding stack, with everyone fighting for daily developer habits.

For a broader look at this shift, our guides on How to Use Claude Code with a Team: Shared Context, Permissions, and MCP and Coding Agent Best Practices cover the operational side of this trend.

What it means for developers

For developers, the outlook is mixed.

On one hand, heavy investment brings faster product updates, more compute, better model quality, and tighter integration. If Cursor trains its own models to reduce reliance on third-party APIs, developers could see better speed, consistency, and pricing.

But developers also care deeply about trust. Can the agent safely touch a production codebase? Can you audit its actions when something breaks? Can your team control its access and visibility?

As agents become more central, these questions grow critical. A fast agent without governance isn't a helpful teammate-it is just a faster way to introduce risk.

Security is a core product feature, not an afterthought. We explored this in Why Your AI Agent Should Never See Your API Keys and An AI Coding Agent Deleted a Production Database. Powerful agents need tighter boundaries than traditional software tools.

Why the model question is the real story

The model strategy is the real story here: if Cursor and SpaceX train more of their models in-house, they gain control over the core intelligence of the product, not just the user interface. While expensive, this is the only way to truly differentiate.

This acquisition is a shortcut to vertical integration in the AI coding market. If every coding tool relies on the same foundation models, the product layer commoditizes quickly. The real competitive advantage shifts to distribution, workflow lock-in, and proprietary data. A custom, code-tuned model allows a company to capture far more of the value chain.

For developers, this means better tools. For startups, it raises the bar. The next generation of coding assistants must offer deep workflow integration, robust security, or a distinct distribution advantage rather than just wrapping an existing API in a new UI.

The industry gets more serious, faster

This deal signals that the coding agent category is maturing. Early-stage markets chase raw growth. Mature markets focus on infrastructure, control, and long-term economics. Cursor's acquisition shows we have entered this second phase.

That has a few consequences:

Capital will shift toward coding infrastructure rather than flashy demos.
Owning the model will become more important than simply accessing it.
Enterprise buyers will demand stricter controls over permissions, logging, and secrets.
Developers will expect agents to manage entire workflows, not just generate code snippets.

The market is shifting from cool features to an operating system for software development.

What teams should do now

If you are building with coding agents, do not wait for the market to settle.

Treat agents like critical infrastructure now. Give them scoped access, keep secrets out of their context, and separate routine coding from destructive actions. Require human approval for any production changes.

Establishing these guardrails early allows you to adopt advanced agents safely. We outline this approach in AI Agent Governance Is the New Enterprise Control Plane and AI Agent Secret Proxy.

For teams, teamcopilot.ai provides these shared workflows, permissions, and secret management out of the box, replacing unmanaged prompts with structured collaboration.

The SpaceX and Cursor deal shows where the category is headed, with coding agents becoming strategic assets. The winning companies won't just offer better chat interfaces; they will provide superior workflows, tighter security controls, better data, and proprietary models. For developers, this means more powerful tools, but it also means the systems you use daily are becoming part of the software control plane. The more capable these agents become, the more carefully they must be managed. The future of AI coding is not just about what agents can write, but what they can safely own.

FAQ

Why is the Cursor acquisition such a big deal?

It shows that coding agents are transitioning from simple productivity add-ons to strategic platform assets embedded in the developer workflow.

Does this mean coding agents are becoming the new IDE?

Not quite, but they are becoming the core intelligence layer within the IDE, handling an increasing share of the actual development work.

Why would SpaceX want an AI coding company?

To secure direct control over its software development pipeline, proprietary workflow data, and model training strategy.

What does a custom model change for coding agents?

A custom, code-specific model improves execution speed, output quality, and cost efficiency while eliminating reliance on external API providers.

What does this mean for developers?

Expect more capable tools alongside intense competition and pressure to integrate AI agents into daily workflows.

Will coding agents replace software engineers?

No. They accelerate drafting, refactoring, and testing, but they do not replace human engineering judgment.

What is the biggest risk with coding agents?

Over-privileged access. An agent with too much visibility or authority can quickly introduce security vulnerabilities or disrupt production environments.

How should teams use coding agents safely?

Implement scoped permissions, mandatory approval gates, detailed audit logs, and secure secret management.

Is this acquisition good or bad for the market?

It drives rapid product innovation but also accelerates consolidation, which could lead to more closed ecosystems.

Where does teamcopilot.ai fit into this trend?

teamcopilot.ai helps teams adopt coding agents safely by providing shared permissions, secret management, and structured workflows.

How to Fine-Tune LLMs on Your Own Data: Open-Source Models, RL Environments, and Evals

Rishabh Poddar — Mon, 15 Jun 2026 04:04:56 +0000

If you use LLMs long enough, you hit the same wall.

The frontier model is impressive, but it is not always the best model for your job. It may be too expensive. It may be too slow. It may be too general. And once you start asking it to follow your company’s rules, tone, domain language, and task structure, the gap between “smart” and “useful” gets obvious fast.

That is where post-training comes in.

The short version is this: if you have enough good data, you can often take an open-source model and make it better for your specific task than a much larger frontier model, while spending less to run it. Success requires the full loop of data, evals, and environments, rather than simple fine-tuning.

Why post-training matters

Pre-trained models know a lot, but they lack context about your business, such as which form fields matter, which edge cases are acceptable, how your style guide looks, or how your internal tools behave when a field is missing. Prompting can help, but it has limits. Retrieval helps, but it does not change the model’s behavior. Post-training does.

That is why a smaller open-source model can beat a giant general model on a narrow task. Once you train on the right examples, the model starts behaving like a specialist instead of a smart generalist.

This pattern is showing up everywhere now, with vendors pushing fine-tuning on open-source models, research teams using evaluation harnesses as reward signals, and open-source RL libraries making the entire process much less mysterious.

Start with supervised fine-tuning

For most teams, supervised fine-tuning is the right first step.

You collect prompt-response pairs from your own data, clean them up, and train the model to imitate the answers you actually want. If your task is classification, structured extraction, support replies, code review comments, or domain-specific writing, SFT often gives the quickest improvement.

The important part is data quality. A few hundred excellent examples usually matter more than a mountain of noisy ones. Your target outputs should look like the real thing. If your best internal answer is short and direct, avoid training on long, polished prose, and make sure to preserve any strict formatting required by your workflow.

A fine-tuned open-source model that knows your task can be much cheaper to serve than calling a frontier model every time, although frontier models still make sense where they are worth the extra spend.

Add RL when the task has a clear signal

Fine-tuning gets you the basic behavior. Reinforcement learning can push things further when the task has a clean reward signal.

That reward signal does not need to be abstract. It can be concrete and mechanical, such as checking whether the generated SQL ran, the code passed tests, the agent completed the workflow, or the answer matched a known correct output. The best RL setups are often the ones where success can be checked automatically.

This is why RL works well for tool use, coding, and agent workflows. You can build a small environment, let the model act in it, and score the outcome. When the model takes the wrong path, the environment flags it, whereas a reliable solution earns a positive reward.

The catch is that RL is only as good as the signal you give it. If the reward is sloppy, the model learns to game the reward instead of solving the task. Instead of starting with RL because it sounds impressive, only use it when the task actually deserves a structured reward system.

Treat RL environments as part of the product

This is the part people skip.

An RL environment is not just a training toy. It is the place where the model proves it can do the job. If you want an agent to use tools, follow procedures, or complete multi-step work, the environment has to resemble the real task closely enough that success means something. This usually requires:

realistic inputs
deterministic graders where possible
frozen fixtures for external data
held-out tasks the model has not seen before
clear pass/fail rules

If you train on a live system and evaluate on the same live system, you can fool yourself. A frozen environment with stable checks is much better for learning whether the model is actually improving or just exploiting quirks.

This matters for team products too. If your internal agent is going to make decisions, fill forms, or act on shared workflows, the training setup should look like the workflow people will actually use.

Use evals before, during, and after training

Evals are not a final checkpoint; they keep you honest. Initial evaluations highlight the model's weaknesses, while checks during training show if you are moving in the right direction, and final tests reveal whether the new model is actually better or just broken in new ways.

A good eval suite usually mixes a few types:

golden-answer tasks for exact correctness
rubric-based scoring for subjective output
task completion checks for agents and workflows
regression tests for the weird edge cases that already hurt you once

The best evals are specific to your use case. When fine-tuning a support model, you should measure policy compliance and escalation paths rather than just fluency, just as training a coding model requires running the tests instead of merely checking code style.

One useful pattern is to turn your eval harness into a reward source. When the evaluator is good enough, it can guide both selection and RL. That gives you a much tighter loop than guessing from model output alone.

Why open-source models often win on ROI

This is where the economics start to matter.

Frontier models are strong, but they come with recurring usage costs and less control over deployment. Open-source models give you more room to shape behavior, run locally or privately, and keep serving costs under control. If the task is narrow enough, that tradeoff can be excellent.

You also get more leverage from your own data. Once you have a decent training set, every improvement compounds. Better data makes better fine-tuning. Better fine-tuning makes better evals. Better evals make better RL. And the cycle keeps tightening.

That is why “use the biggest model” is not the right default. The better question is whether the task is worth specializing. If it is, an open-source model on your data often gives you better performance per dollar.

A practical workflow

If you want to do this well, keep the sequence boring:

Define the task clearly.
Collect a clean dataset from real examples.
Build evals before training anything.
Start with supervised fine-tuning.
Add RL only when the environment and reward are solid.
Re-run the evals and compare against the baseline.
Deploy only after you can explain why the new model is better.

While this approach isn't flashy, it works, and it fits team workflows better than one-off prompting. TeamCopilot.ai provides this structure for broader agent workflows, making the system repeatable, auditable, and safe enough for a team to rely on.

If you want a related angle, AI Agent Governance Is the New Enterprise Control Plane and Coding Agent Best Practices: How to Set Up AI Agents Securely and Productively are useful companions.

Where this breaks down

Post-training is not magic. It works best when the task is stable and the data is good. It works less well when the problem changes every week or the label quality is weak.

It also does not remove the need for a strong fallback model. Sometimes the best setup is a specialized open-source model for the common path and a frontier model for the weird edge cases. That hybrid setup is often the most practical one.

The real mistake is treating model choice like a religion. Instead, use the smallest model that does the job, fine-tune it on your data, measure the results honestly, and keep the option that performs best rather than the one that is newest.

FAQ

What is post-training in LLMs?

Post-training is everything you do after pre-training to make a model more useful for a specific task. That includes supervised fine-tuning, preference optimization, reinforcement learning, and similar adaptation methods.

Is fine-tuning always better than prompting?

No. Prompting is faster to try and often good enough for small tasks. Fine-tuning becomes worth it when you need consistent behavior, lower latency, lower cost, or better results on your own data.

When should I use RL instead of supervised fine-tuning?

Use RL when you can define a reliable reward signal or a clear success condition. If the task has a measurable outcome, RL can help push the model beyond imitation.

What makes a good RL environment?

A good RL environment mirrors the real task closely, has clear grading, uses deterministic fixtures when possible, and avoids hidden shortcuts that let the model game the reward.

Why are evals so important?

Because they tell you whether the model actually got better. Without evals, training turns into guesswork. With good evals, you can compare models, catch regressions, and decide whether the change was worth it.

Can an open-source model really beat a frontier model?

Yes, on a narrow task with good data, it often can. The smaller model may be worse in general, but better on your specific workflow.

Is this cheaper than using frontier models?

Usually, yes, once the model is trained and deployed at scale. You pay upfront for data and training, but ongoing inference can be much cheaper.

What kind of data do I need?

You need real examples of the task you want the model to do. Clean prompt-response pairs for SFT, plus outcome data or verifier logic if you want RL.

Do I need a huge dataset?

Not always. Good data matters more than a huge dataset. A smaller, well-curated set often beats a large noisy one.

Where does TeamCopilot.ai fit in?

TeamCopilot.ai is useful when you want the surrounding process to stay controlled. If your team is building or operating AI workflows, it helps keep permissions, approvals, and automation structured instead of ad hoc.

Should I ever keep using frontier models?

Absolutely. Frontier models still make sense for hard reasoning, broad coverage, or tasks that change too fast to justify training. The point is to use them where they earn their cost.

Anthropic's Fable 5 Block Is a Reminder to Pick the Smallest Model That Passes

Rishabh Poddar — Sun, 14 Jun 2026 04:58:36 +0000

The sudden block of Anthropic's Fable 5 shows how vulnerable modern software is when it quietly depends on a single external model.

A frontier model launched, gained rapid adoption, and was suddenly restricted by a government order. While the political details and technical claims remain highly contested, the operational lesson is clear: access is never guaranteed, and raw capability does not make a model the right choice.

Instead of asking for the most powerful model available, teams should ask for the smallest model that passes their evaluations for a specific task.

What happened

On June 12, 2026, the U.S. government reportedly ordered Anthropic to restrict access to Fable 5 and Mythos 5 for foreign nationals, citing national security concerns. Anthropic responded by disabling access more broadly to ensure compliance. The lack of public technical details makes this incident particularly notable. Even for a prominent company like Anthropic, model access can vanish overnight when policy, national security, and export controls collide.

If you want the background on the model itself, see What Is Claude Fable 5? Capabilities, Benchmarks, Pricing, and How to Access It.

Why this matters

Most teams treat model selection as a capability problem, comparing benchmarks and context windows before picking the strongest option. While this approach works for demos, production systems require a different standard. In a real workflow, unnecessary capability brings extra cost, latency, variability, and risk. If a smaller model can do the job, a larger one only increases your potential blast radius. This is especially true for agents handling files, tools, and credentials; narrow tasks require a model that reliably meets the requirements rather than one that merely excels on generic benchmarks.

That same mindset shows up in AI Agent Governance Is the New Enterprise Control Plane and Why Your AI Agent Should Never See Your API Keys. The model is only one part of the system. Governance matters just as much.

Why the smallest passing model is usually the right one

Choosing the smallest model that clears your evaluations offers several practical advantages. First, smaller models lower operational costs and run faster, which directly improves the user experience. They also reduce risk; with less unnecessary general capability, there are fewer opportunities for unexpected behavior. While this doesn't make them safe by default, it limits the potential damage. Finally, smaller models are much easier to replace. If a provider changes its pricing, policies, or access terms, a team using a smaller, highly targeted model can migrate far more easily. The Fable 5 block proves that even an excellent model can be an unreliable dependency.

How to choose the smallest model that works

Finding the right model requires a structured evaluation set rather than intuition. Start by gathering real examples from your target task, such as actual support tickets for classification, real notes for summarization, or production-grade workflows for action-taking.

Use these to build a compact evaluation set containing normal examples, edge cases, ambiguities, historical production failures, and a few deliberately difficult scenarios. Once you run this set against several models, avoid chasing the highest score at all costs; instead, aim for the smallest model that meets your acceptance threshold.

In practice, you should measure latency, cost, pass rates, and the types of mistakes the model makes. If two models both pass, choose the smaller one. If the smaller model barely squeaks by, keep it under review and add more difficult examples to your evaluation set. Anthropic itself advocates for starting with small, realistic test sets. Defining success first and iterating is far more effective than starting with the largest model and hoping brute force compensates for a poorly defined task.

What a good eval set looks like

A good evaluation set is boring in the best way: close to your real task, stable enough to rerun, and small enough for manual inspection. Avoid building a massive benchmark before you even have a working workflow. A set of 20 to 50 carefully chosen examples is often plenty to make a clear decision early on. The most useful test cases usually come from real mistakes, like a misread document, a wrong routing decision, or a failed tool call. Turning these failures into tests is far more valuable than using generic prompts from a benchmark blog post. A task is simply not ready for production until you can explain exactly why the model passed.

This is also a governance problem

Model selection is often treated like an engineering detail, but it is not. The model you choose dictates what your system can do, what it is allowed to access, and how much damage it can cause if it fails. This is why permissions, approvals, and audit trails are critical once models handle real work. A system like teamcopilot.ai helps keep these choices inside an environment where access, approvals, and secrets are managed properly. The goal is to make AI usable without turning every model choice into a risk multiplier.

The practical takeaway

The Fable 5 block reminds us that frontier models can be impressive yet unstable dependencies, and that most tasks simply do not require the largest model available. To build a durable setup, follow these steps:

Define the task clearly.
Build a small eval set from real examples.
Test multiple models, starting from the smallest plausible option.
Pick the smallest model that passes.
Re-run the evals whenever you change the task or the model.

This process takes slightly longer upfront, but it is much faster than debugging a bad production choice later.

FAQ

The Fable 5 Incident and Frontier Model Risks

Anthropic disabled access to Fable 5 following a government order tied to national security concerns and export controls. While the public explanation remains thin, this event highlights the inherent risks of relying solely on frontier models for production. This does not mean frontier models are too risky to use entirely, but they should be selected carefully and earn their spot through rigorous testing rather than default assumptions.

Designing and Scaling Your Evaluation Sets

An evaluation set is a curated group of test examples representing the task you want the model to handle, allowing you to compare models consistently. When starting out, keep the set small - 20 to 50 real examples are often better than a massive synthetic benchmark. Your set should include ordinary cases, edge cases, historical production failures, and a few intentionally difficult scenarios. If you don't have an evaluation set yet, start by turning your recent production failures, bad outputs, or support escalations into your first test cases.

Choosing the Right Model and Measuring Success

You should measure latency, cost, and the types of mistakes the model makes. Not necessarily - use the smallest model that passes your task requirements. If a smaller model fails important edge cases, move up the capability ladder until it passes. If the task changes or grows more complex over time, simply re-run your evaluation set to ensure your chosen model still fits.

Governance, Safety, and Control

Cost is important, but control is often the primary driver. Smaller models are easier to justify, replace, and operate safely. However, safety still depends heavily on permissions, approvals, and what the model is allowed to touch. For sensitive workflows, your evaluations must be stricter and your guardrails stronger, ensuring that model selection and access control are designed together from the start.

Is Siri AI? How Apple's Voice Assistant Really Works

Rishabh Poddar — Fri, 12 Jun 2026 04:09:15 +0000

Apple finally gave Siri the kind of upgrade people have been asking for, on and off, for years.

The new Siri AI is not just better speech recognition or a slightly smarter search box. Apple says it can understand what is on your screen, use personal context across messages and email, answer questions from the web, and take actions across apps. That moves Siri from a voice shortcut into something that looks a lot more like a real assistant.

That matters because Siri has always been one of the most visible consumer AI products on earth. When Apple changes Siri, it changes what a lot of people think an assistant should be able to do.

What changed in practice

At WWDC 2026, Apple introduced Siri AI as a rebuilt assistant powered by Apple Intelligence. The changes are pretty straightforward:

It can use personal context to find things in your messages, emails, photos, and other apps.
It has onscreen awareness, so it can answer questions about what you are currently looking at.
It can reach out to the web for up-to-date answers.
It can perform more systemwide actions across apps.
It now has a dedicated app for conversation history.
It includes expanded writing and editing tools.

Apple also leaned hard on privacy. Siri AI runs through Apple’s on-device and Private Cloud Compute architecture, which is the company’s way of saying it wants the assistant to stay useful without becoming a data leak.

That privacy angle is the interesting part. Most AI products get better by seeing more. Apple is trying to get more capable while seeing less.

Why this feels different

Old Siri was mostly a command layer. You asked for a timer, a reminder, a weather check, or a quick lookup. It was useful, but it stayed in a small lane.

Siri AI is trying to do something broader. If a friend texts you a restaurant recommendation, Siri should be able to find it. If you are looking at a message about a trip, it should help you act on it. If you are writing, it should help draft and edit in context.

That is a very different product shape.

Instead of just answering questions, the assistant can now handle multi-step tasks for you—like finding a flight confirmation in your email and adding it directly to your calendar without you having to copy and paste.

Why teams should care

While the Siri update is a consumer story, the lesson is bigger than Apple: as assistants get more powerful, the hard part stops being raw intelligence and becomes control. Who can the assistant see? What can it touch? When should it ask for approval? How do you keep secrets safe? How do you know what it did later?

That is the same reason TeamCopilot exists. Teams do not just need a smart assistant. They need a shared assistant they can trust, with permissions, approvals, workflows, and secret handling built in.

Once AI starts acting on your behalf, governance stops being a nice-to-have. If you want to see how to manage these permissions and security risks in your own team, these resources are a good place to start:

What to watch next

Siri AI's real test lies in daily use rather than keynote demos. Will people trust it to search across personal data? Will it stay fast enough to feel natural? Will it actually replace some of the tiny tasks people do every day? And will Apple keep the privacy promise intact as the assistant gets more capable?

Those questions matter because they will shape the rest of the market too. If Apple makes a privacy-first assistant feel genuinely useful, it will push every other assistant maker to explain how they handle memory, context, and action.

That pressure helps users, but it also helps set a better baseline for teams building internal agents. The future belongs to systems designed to act safely.

What this means for TeamCopilot

Siri AI is a good reminder that people do not want tools that only answer questions; they want tools that understand context, take action, and stay out of the way. But once an assistant can do more, it also needs more guardrails.

That is the gap TeamCopilot is built for. Shared skills, workflows, secret management, and approval controls let teams use AI agents without handing them unchecked access.

The real challenge isn't just making Siri smarter—it's building an assistant that users and teams can actually trust with their sensitive data.

FAQ

Is Siri AI now?

Yes. Apple has rebuilt Siri around Apple Intelligence, with personal context, onscreen awareness, web answers, and app actions.

What is new in Siri AI?

The big changes are contextual understanding, better conversation, a dedicated app, visual intelligence, and stronger writing tools.

Does Siri AI use personal data?

It can use personal context from apps like Messages, Mail, and Photos, but Apple says it does so through privacy-preserving architecture and on-device processing where possible.

Is Siri AI the same as ChatGPT or Gemini?

Not really. Siri AI is Apple’s own assistant layer, built into the operating system and designed around Apple hardware and privacy.

Why does Siri AI matter for businesses?

It shows that assistants are moving from simple chat into real action. That is the same shift businesses face when they adopt AI agents internally.

What is the biggest risk with more powerful AI assistants?

The biggest risk is overreach. If an assistant can see too much or act too freely, it can create privacy, security, and reliability problems.

How is TeamCopilot different from Siri AI?

Siri AI is a personal consumer assistant built into Apple devices. TeamCopilot is a shared team agent with skills, workflows, approvals, and secret controls for business use.

What is the main takeaway from Apple's Siri AI launch?

The main takeaway is that as assistants gain the power to act on our behalf, security and trust become just as important as capability.

How to Humanize AI Text Without Sounding Robotic

Rishabh Poddar — Fri, 12 Jun 2026 04:00:55 +0000

AI text usually sounds robotic for the same boring reasons. The sentences are too even. The transitions are too polished. The wording is technically fine, but it never quite sounds like a person.

So the fix is not just "make this sound human." You need a method that checks the draft, spots the AI tells, and rewrites it in passes until it reads naturally.

That is what the code below does.

What "humanized" actually means

Humanized text is not slangy or messy. It keeps the meaning intact, but it sounds like a real person wrote it once instead of a model polishing it three times.

In practice, that means:

sentence lengths vary
ideas do not all arrive in the same shape
the tone matches the audience
the wording is specific instead of generic
the draft does not lean on obvious AI crutches like repetitive transitions, fake nuance, or overclean symmetry

The code at a glance

The code takes a long input string and runs it through an iterative loop.

It splits the text into markdown chunks using top-level ## headings.
It runs a detector prompt on each chunk in parallel.
It collects the strongest AI-writing signals.
It rewrites the full original text using those findings.
It repeats until the text looks clean or it hits the max iteration count.

The code does not guess from vibes. It asks the model to point at concrete snippets, explain why they sound AI-like, and say what should change.

The full workflow code

This is the actual implementation.

import argparse
import json
import os
import sys
import re
import uuid
from typing import Any, Dict, List
from concurrent.futures import ThreadPoolExecutor, as_completed
from pathlib import Path

from google import genai
from google.genai import types
from pydantic import BaseModel, Field


MODEL = "gemini-3.5-flash"
INPUT_COST_PER_1M = 1.50
OUTPUT_COST_PER_1M = 9.00


def load_local_env_var(key_name: str) -> str:
    env_path = os.path.join(os.path.dirname(__file__), ".env")
    if not os.path.exists(env_path):
        raise KeyError(key_name)

    with open(env_path, "r", encoding="utf-8") as handle:
        for line in handle:
            line = line.strip()
            if not line or line.startswith("#") or "=" not in line:
                continue
            name, value = line.split("=", 1)
            if name.strip() == key_name:
                value = value.strip().strip('"').strip("'")
                if value:
                    return value

    raise KeyError(key_name)


if "GEMINI_API_KEY" not in os.environ:
    os.environ["GEMINI_API_KEY"] = load_local_env_var("GEMINI_API_KEY")

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
OUTPUT_DIR = Path(__file__).resolve().parent / "data"


class Snippet(BaseModel):
    snippet: str = Field(description="Short excerpt from the text")
    reason: str = Field(description="Why the excerpt reads AI-like")
    fix: str = Field(description="What to change")


class DetectionResult(BaseModel):
    has_issues: bool = Field(description="Whether the text has AI-writing issues")
    snippets: List[Snippet] = Field(default_factory=list, max_length=5)


class RewriteResult(BaseModel):
    rewritten_text: str = Field(description="The full rewritten text")


def get_usage_count(usage: Any, names: List[str]) -> int:
    for name in names:
        value = getattr(usage, name, None)
        if value is not None:
            return int(value)
    return 0


def estimate_cost(prompt_tokens: int, output_tokens: int) -> float:
    return (prompt_tokens / 1_000_000.0) * INPUT_COST_PER_1M + (output_tokens / 1_000_000.0) * OUTPUT_COST_PER_1M


def trim_to_first_words(text: str, word_count: int = 6) -> str:
    words = text.split()
    if len(words) <= word_count:
        return text
    return " ".join(words[:word_count])


def split_into_chunks(text: str) -> List[str]:
    chunks: List[str] = []
    current: List[str] = []

    for line in text.splitlines():
        if re.match(r"^##\s+", line):
            if current:
                chunk = "\n".join(current).strip()
                if chunk:
                    chunks.append(chunk)
                current = []
            current.append(line)
        else:
            current.append(line)

    if current:
        chunk = "\n".join(current).strip()
        if chunk:
            chunks.append(chunk)

    return chunks or [text]


def call_gemini(prompt: str, *, response_model: type[BaseModel]) -> tuple[str, BaseModel, int, int, float]:
    response = client.models.generate_content(
        model=MODEL,
        contents=prompt,
        config=types.GenerateContentConfig(
            temperature=0.2,
            top_p=0.95,
            response_mime_type="application/json",
            response_schema=response_model,
        ),
    )

    raw_text = (response.text or "").strip()
    if not raw_text:
        raise RuntimeError("Gemini returned empty text")

    parsed = response_model.model_validate_json(raw_text)
    usage = getattr(response, "usage_metadata", None)
    prompt_tokens = get_usage_count(usage, ["prompt_token_count", "input_token_count"])
    output_tokens = get_usage_count(usage, ["candidates_token_count", "output_token_count", "response_token_count"])
    cost = estimate_cost(prompt_tokens, output_tokens)
    return raw_text, parsed, prompt_tokens, output_tokens, cost


def _detect_single_chunk(index: int, chunk_text: str) -> tuple[int, str, List[Dict[str, Any]], float, int, int, int]:
    detection_raw, detection, detection_prompt_tokens, detection_output_tokens, detection_cost = call_gemini(
        build_detection_prompt(chunk_text),
        response_model=DetectionResult,
    )

    chunk_snippets = [
        {**snippet.model_dump(), "snippet": trim_to_first_words(snippet.snippet)}
        for snippet in detection.snippets
    ]
    return index, detection_raw, chunk_snippets, detection_cost, detection_prompt_tokens, detection_output_tokens, len(chunk_snippets)


def detect_issues_in_chunks(chunks: List[str]) -> tuple[List[Dict[str, Any]], float, int]:
    return detect_issues_in_chunks_parallel(chunks, verbose=True)


def detect_issues_in_chunks_silent(chunks: List[str]) -> tuple[List[Dict[str, Any]], float, int]:
    return detect_issues_in_chunks_parallel(chunks, verbose=False)


def detect_issues_in_chunks_parallel(chunks: List[str], verbose: bool) -> tuple[List[Dict[str, Any]], float, int]:
    all_snippets: List[Dict[str, Any]] = []
    seen = set()
    total_cost = 0.0
    total_chunks = 0

    max_workers = max(1, min(8, len(chunks)))
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        futures = [executor.submit(_detect_single_chunk, index, chunk_text) for index, chunk_text in enumerate(chunks, start=1)]
        chunk_results = [future.result() for future in as_completed(futures)]

    for index, detection_raw, chunk_snippets, detection_cost, detection_prompt_tokens, detection_output_tokens, snippet_count in sorted(chunk_results, key=lambda row: row[0]):
        if verbose:
            print(f"\n=== Chunk {index} Detection Result ===")
            print(detection_raw)
            print(f"Chunk {index} detection cost: ${detection_cost:.6f} ({detection_prompt_tokens} input tokens, {detection_output_tokens} output tokens)")
            if chunk_snippets:
                print(json.dumps(chunk_snippets, ensure_ascii=False, indent=2))

        for snippet in chunk_snippets:
            key = (snippet.get("snippet"), snippet.get("reason"), snippet.get("fix"))
            if key in seen:
                continue
            seen.add(key)
            all_snippets.append(snippet)

        total_cost += detection_cost
        total_chunks += 1

    return all_snippets, total_cost, total_chunks


def process_text(input_text: str, max_iterations: int = 10, rewrite_style: str = "", verbose: bool = True) -> dict:
    current_text = input_text
    total_cost = 0.0
    iteration = 0
    first_iteration_issues: List[Dict[str, Any]] = []
    forced_rewrite_done = False

    for iteration in range(1, max_iterations + 1):
        chunks = split_into_chunks(current_text)
        if verbose:
            print(f"Iteration {iteration}: {len(chunks)} chunk(s)")
        all_snippets, detection_cost, _ = detect_issues_in_chunks_parallel(chunks, verbose=verbose)

        if iteration == 1:
            first_iteration_issues = all_snippets

        has_issues = bool(all_snippets)
        if verbose:
            print(f"Iteration {iteration}: {len(all_snippets)} issue(s) found")

        iteration_cost = detection_cost

        should_force_rewrite = bool(rewrite_style.strip()) and not forced_rewrite_done
        should_rewrite = has_issues or should_force_rewrite

        if not should_rewrite:
            total_cost += iteration_cost
            if verbose:
                print(f"Iteration {iteration} total cost: ${iteration_cost:.6f}")
            break

        rewrite_raw, rewrite_output, rewrite_prompt_tokens, rewrite_output_tokens, rewrite_cost = call_gemini(
            build_rewrite_prompt(input_text, all_snippets, rewrite_style=rewrite_style),
            response_model=RewriteResult,
        )
        current_text = rewrite_output.rewritten_text
        forced_rewrite_done = True
        iteration_cost += rewrite_cost
        total_cost += iteration_cost
        if verbose:
            print(f"Iteration {iteration}: rewrite applied")

    return {
        "final_output": current_text,
        "total_cost": round(total_cost, 6),
        "iterations": iteration,
        "model": MODEL,
        "first_iteration_issues": first_iteration_issues,
    }




def build_detection_prompt(text: str) -> str:
    return f"""Audit the text for AI-writing tells.

Focus on concrete signals, not vague vibes:

- Em dash overuse: repeated `—`, lists built around em dashes, em dashes used as a default stylistic crutch, or multiple paragraphs that lean on em dashes for rhythm.
- Contrast formulas: "it's X, not Y", "not only X, but also Y", "this isn't just X, it's Y", "the real answer isn't X".
- Meta-openers: "what usually gets skipped here is...", "what people often miss is...", "the part people forget is...", "what matters most is...", "what gets overlooked is...", "this is exactly the sort of...", "this is basically why...", "this is the kind of...".
- One-line paragraph patterns: lots of short single-sentence paragraphs in a row.
- Paragraph stubs: a paragraph that starts with a short setup sentence and then immediately follows with a tiny paragraph of 2-5 words, or a paragraph that is itself only 2-5 words long.
- Outline scaffolding: numbered headings or label-only sections like `### 1. Security`, `### 2. Reliability`, or repeated short section labels that read like an outline instead of prose.
- Choppy fragmentation: paragraphs with 2-4 very short sentences that all carry pieces of one idea and could naturally become a single sentence. Prioritize this signal even if the paragraph also contains a meta-opener.
- Template transitions: "that works, until it doesn't", "in today's world", "at the end of the day", "ultimately", "overall".
- Symmetry: repeated sentence openings, repeated clause shapes, evenly balanced comparisons, or neat bullet/list structures that feel engineered.
- Generic polish: buzzwords, hedging, fake nuance, or conclusion sentences that sound like a marketing page.
- Sycophancy: excessive praise toward the user, flattering language, "you nailed it", "great question", "this is exactly the right approach", or over-agreeable validation that adds no substance.
- Over-polished cadence: text that is technically clean but too symmetrical, too tidy, too templated, or too optimized for scannability.
- Repetitive feature-list formatting: bold labels, em-dash lists, or repeated "X — Y" constructions that create a slide-deck feel.

Return JSON only in this exact shape:
{{
  "has_issues": true|false,
  "snippets": [
    {{"snippet": "short identifying excerpt", "reason": "short reason", "fix": "short fix"}}
  ]
}}

Rules:
- Return at most 5 snippets.
- Snippets must be short. Use only the first few words needed to identify the line.
- Keep `reason` and `fix` concise.
- If the text is natural, return `has_issues: false` and `snippets: []`.
- Prefer the strongest signals only.
- If a paragraph splits one idea across multiple short sentences, flag that fragmentation even if each sentence is individually understandable.
- If a paragraph is just 2-5 words, always flag it.

Text:
{text}"""


def build_rewrite_prompt(original_text: str, issues: List[Dict[str, Any]], rewrite_style: str = "") -> str:
    issues_json = json.dumps(issues, ensure_ascii=False, indent=2)
    rewrite_style_block = f"\nAdditional rewrite style guidance:\n{rewrite_style}\n" if rewrite_style.strip() else ""
    return f"""Rewrite the text so it sounds human and natural while preserving meaning, facts, proper nouns, and formatting that still helps the content.

Use these rules:
- Direct over ornate.
- Specific over vague.
- Mix short and long sentences.
- Prefer simple verbs and concrete nouns.
- Delete fluff instead of disguising it.
- Avoid robotic symmetry, generic closings, and over-polished transitions.
- Keep the level of formality appropriate to the original content.

Address these flagged issues:
{issues_json}
{rewrite_style_block}

Return valid JSON only with this schema:
{{
  "rewritten_text": "the full rewritten text"
}}

Original text:
{original_text}"""


def main() -> int:
    parser = argparse.ArgumentParser(description="Humanise text with iterative Gemini rewrites.")
    parser.add_argument("--input_text", required=True, help="The text to humanise")
    parser.add_argument("--max_iterations", type=int, default=10, help="Maximum rewrite/detection loops to run")
    parser.add_argument("--rewrite_style", default="", help="Additional style guidance for the rewrite prompt")
    args = parser.parse_args()

    summary = process_text(args.input_text, max_iterations=args.max_iterations, rewrite_style=args.rewrite_style, verbose=True)
    OUTPUT_DIR.mkdir(parents=True, exist_ok=True)
    output_path = OUTPUT_DIR / f"final_rewrite_{uuid.uuid4().hex}.json"
    output_path.write_text(summary["final_output"], encoding="utf-8")
    console_summary = {
        "output_path": str(output_path),
        "iterations": summary["iterations"],
        "total_cost": summary["total_cost"],
        "model": summary["model"],
    }
    print(json.dumps(console_summary, ensure_ascii=False, indent=2))
    return 0


if __name__ == "__main__":
    try:
        raise SystemExit(main())
    except Exception as exc:
        print(f"Error: {exc}", file=sys.stderr)
        raise SystemExit(1)

How the code works

The code looks long, but the logic is simple.

1. It loads Gemini securely

The workflow expects GEMINI_API_KEY to be present in the runtime environment. If it is not there, it tries to read a local .env file inside the workflow folder.

That matters because TeamCopilot workflows are meant to run with secrets injected safely, not pasted into prompts or hardcoded into source.

2. It uses structured outputs

Both the detector and the rewrite step use Pydantic models.

That means the model cannot just return a messy blob of text. It has to return valid JSON in the shape the workflow expects:

DetectionResult gives has_issues plus up to five flagged snippets
RewriteResult gives the full rewritten text

It makes the workflow predictable, which is what you want if other people are going to reuse the output.

3. It scans in chunks

The workflow splits the input on top-level ## headings so it can inspect each section separately.

That helps because long blog drafts usually mix clean sections with sections that still sound synthetic. Chunking keeps the detector focused instead of asking it to judge a giant wall of text all at once.

4. It runs detection in parallel

Each chunk is checked in parallel with a thread pool, which keeps the process moving on longer drafts.

The detector is not just looking for one thing. It flags patterns like:

em dash overuse
contrast formulas like "it's X, not Y"
meta-openers like "what people often miss is"
overclean section scaffolding
repetitive sentence shapes
generic closing lines

5. It rewrites only when needed

If the detector finds issues, the workflow rewrites the full original text using those findings.

If it finds nothing, it stops early.

There is one exception. If you pass a non-empty rewrite_style, the workflow forces at least one rewrite pass even if the detector says the text is clean. That is useful when you want a specific voice or house style layered in.

6. It writes the final result to disk

When the loop is done, the workflow writes the final rewrite to a file in data/ and prints a small JSON summary to stdout.

That summary includes:

output_path
iterations
total_cost
model

How to use it

In TeamCopilot, the workflow takes these inputs:

input_text: the text you want humanized
max_iterations: how many detect and rewrite loops to run, default 10
rewrite_style: optional style guidance that forces at least one rewrite pass

A simple run looks like this.

{
  "input_text": "AI tools are changing how teams work. We need to use these tools to make our workflows faster and more efficient, which ultimately helps us deliver better results.",
  "max_iterations": 10,
  "rewrite_style": "Keep it warm, practical, and a little conversational."
}

The workflow might return a summary like this:

{
  "output_path": "data/final_rewrite_7a1d8f2c3d9e4b31b4d2d1ef9c1c5e5f.json",
  "iterations": 2,
  "total_cost": 0.008412,
  "model": "gemini-3.5-flash"
}

The file at output_path contains the final rewritten text.

Example inputs and outputs

Here are simple before and after examples.

Example 1

Input

You are exactly right! The code indeed has a bug.

Output

The code has a bug.

Here is another example with a style guide added.

Example 2

Input

That's exactly the right approach. The way to solve this problem is to use an iterative loop with a detector and a rewrite step.

`rewrite_style`

Write it as a friendly reddit comment in first person style.

Output

I've had the best luck tackling this with an iterative loop. You basically just need a detector and a rewrite step to get it done.

Why this is better than a single rewrite prompt

A single prompt can help, but it usually stops at surface cleanup.

This workflow is stronger because it separates the problem into two jobs:

find the AI tells
rewrite around those tells

That is how editors work too. First they spot the bad habits. Then they fix them. Then they read it again.

FAQ

What does the code actually do?

It audits text for AI-writing patterns, flags the strongest issues, rewrites the full draft, and repeats until the text reads naturally or the maximum iteration count is reached.

Does it change the meaning of the text?

It is designed not to. The rewrite prompt tells the model to preserve meaning, facts, proper nouns, and useful formatting.

Why does it split text into chunks?

Long drafts are easier to inspect section by section. Chunking also lets the detector focus on one section at a time instead of making one big judgment on the entire post.

Why use structured output instead of plain text?

Structured output makes the workflow reliable. The detector must return a clear JSON object with snippets, reasons, and fixes. The rewrite step must return the final text in a known shape.

What if the detector finds nothing?

The workflow stops early and returns the current text. That saves time and cost.

What does `rewrite_style` do?

It adds extra guidance for tone or voice. If you pass a non-empty value, the workflow runs at least one rewrite pass even when the detector does not find obvious issues.

Can I use this on blog posts only?

No. It can be used on blog posts, docs, support text, internal notes, landing pages, and other long-form writing.

What kind of AI tells does the code look for?

It looks for things like repetitive transitions, overly symmetrical sentence shapes, one-line paragraph patterns, vague buzzwords, fake nuance, em dash overuse, and contrast formulas that read like template writing.

What is the best input format?

Use a full draft with headings and normal paragraph flow. The code is built to work on substantial text, not just a sentence or two.

How many iterations should I use?

The default is 10. In practice, most drafts should not need that many. If the text is already decent, the code stops early.

Is the output deterministic?

No. It uses a model, so two runs can produce slightly different rewrites. The structure of the code stays the same, though, which is what matters for repeatability.

Does this replace human editing?

No. It gets the draft much closer, but the best results still come from a human pass at the end.

How is this different from a generic AI humanizer?

Most generic tools just rewrite surface phrasing. This code does the more useful thing: it detects the patterns first, rewrites in passes, and gives you a predictable process you can reuse.

How to Visually Debug Multi AI-Agent Flows

Rishabh Poddar — Wed, 18 Jun 2025 14:30:00 +0000

Multi AI-Agent systems represent a significant advancement in software development, characterized by two fundamental aspects:

Collaborative Intelligence: Multiple AI agents working together to achieve shared objectives, each contributing their specialized capabilities.
Dynamic Decision Making: Systems that employ AI-driven tool calling to determine execution paths based on real-time context, rather than following predetermined logic flows.

The dynamic nature of these systems presents a unique challenge: understanding the flow of logic becomes increasingly complex as the system scales. A single query might trigger no tool calls, while another could initiate a cascade of nested interactions where AI agents themselves trigger additional tool calls. This complexity makes system behavior difficult to track and debug.

To address this challenge, I'm introducing AgentGraph, an open-source library that seamlessly integrates with Python or Node.js backends. This tool captures and visualizes LLM interactions and tool calls in real-time, presenting them as an interactive graph that provides clear visibility into system behavior.

Visualizing Agent Interactions

Let's examine a practical example: a database query agent with access to two tools:

SQLAgent: Converts natural language queries into SQL
DatabaseAgent: Executes SQL queries and returns results

Here's how the agent graph visualizes different types of interactions:

Query 1: "Hi there!"

A simple greeting that doesn't require database access results in no tool calls:

Query 2: "How many users do I have?"

This query triggers a sequence of tool calls:

SQLAgent converts the query to SQL
DatabaseAgent executes the query

The main agent's graph shows:

The second bubble contains the user input (also indicating that the LLM used tools), followed by the final response bubble. Clicking the second bubble reveals the tool calls:

The LLM first calls SQLAgent, then DatabaseAgent. Clicking on the SQLAgent row shows its subgraph:

The subgraph displays the tool input (orange box), output (green box), and complete LLM chat history. While this example shows a simple tool, the visualization scales to handle complex nested tool calls. The DatabaseAgent's subgraph shows:

Since this tool doesn't use an LLM, it simply displays the input and output.

Integration Guide

Let's walk through implementing AgentGraph in a Node.js backend. You can find the complete example code here. While we'll focus on Node.js, the implementation is similar for Python backends.

To get started, install the AgentGraph package:

npm install @trythisapp/agentgraph

Setting Up the Main Agent

The core of the integration involves wrapping your LLM calls with AgentGraph's callLLMWithToolHandling function. Here's how to set up the main agent:

import { callLLMWithToolHandling, clearSessionId } from "@trythisapp/agentgraph";
import { v4 as uuidv4 } from 'uuid';

async function mainAgent(userInput: string, sessionId: string) {
    let input: OpenAI.Responses.ResponseInput = [{
        role: "system",
        content: `You are a helpful assistant for querying a database...`
    }, {
        role: "user",
        content: userInput
    }];

    try {
        let response = await callLLMWithToolHandling(
            "mainAgent",           // Agent name for visualization
            sessionId,             // Unique session identifier
            undefined,             // Tool ID (undefined for main agent)
            async (inp) => {       // LLM call function
                return await openaiClient.responses.create({
                    model: "gpt-4.1",
                    input: inp,
                    tools: [/* tool definitions */],
                });
            },
            input,                 // Input messages
            [/* tool implementations */]
        );

        console.log(response.output_text);
    } finally {
        clearSessionId(sessionId);  // Clean up session data
    }
}

Session Management

Each interaction requires a unique session ID to track the conversation flow:

let sessionId = uuidv4();
console.log(`Session ID: ${sessionId}. File is saved in ./agentgraph_output/${sessionId}.json`);

The session ID serves two purposes:

Visualization: Groups related interactions in the same graph
File Output: Creates a JSON file with the complete interaction trace

Always call clearSessionId(sessionId) when the session ends to clean up memory.

Defining Tools

Tools are defined using OpenAI's function calling format within the LLM call:

tools: [{
    type: "function",
    strict: true,
    name: "SQLAgent",
    description: "Use this tool when you need to convert the natural language query into a SQL query",
    parameters: {
        type: "object",
        properties: {
            query: {
                type: "string",
                description: "The natural language query to convert into a SQL query"
            }
        },
        required: ["query"],
        additionalProperties: false
    }
}, {
    type: "function",
    strict: true,
    name: "databaseAgent",
    description: "Use this tool when you need to execute the SQL query and return the results",
    parameters: {
        type: "object",
        properties: {
            query: {
                type: "string",
                description: "The SQL query to execute"
            }
        },
        required: ["query"],
        additionalProperties: false
    }
}]

Implementing Tool Handlers

The final parameter of callLLMWithToolHandling is an array of tool implementations:

[{
    toolName: "SQLAgent",
    impl: async ({ query }: { query: string }, toolId: string) => {
        return runSQLAgent(sessionId, toolId, query);
    }
}, {
    toolName: "databaseAgent", 
    impl: async ({ query }: { query: string }) => {
        return runDatabaseAgent(query);
    }
}]

Each tool implementation receives:

Parameters: The arguments passed by the LLM (destructured from the first parameter)
Tool ID: A unique identifier for this specific tool call (used for nested visualization)

Creating Nested Agents

For tools that use LLMs internally (like SQLAgent), you create nested agents by calling callLLMWithToolHandling again:

async function runSQLAgent(sessionId: string, toolId: string, query: string): Promise<string> {
    let input: OpenAI.Responses.ResponseInput = [{
        role: "system",
        content: `You are an expert SQLite SQL query generator...`
    }, {
        role: "user",
        content: query
    }];

    let response = await callLLMWithToolHandling(
        "SQLAgent",        // Nested agent name
        sessionId,         // Same session ID
        toolId,            // Tool ID from parent call
        async (inp) => {
            return await openaiClient.responses.create({
                model: "gpt-4.1",
                input: inp,
                text: {
                    format: {
                        type: "json_schema",
                        name: "sqlQuery",
                        schema: {/* JSON schema */}
                    }
                }
            });
        },
        input,
        []                 // No tools for this agent
    );

    return response.output_text;
}

Notice how the nested agent:

Uses the same sessionId to maintain session continuity
Receives the toolId from the parent to establish the parent-child relationship
Can have its own tools or none at all

Simple Tool Implementation

For tools that don't use LLMs (like databaseAgent), the implementation is straightforward:

async function runDatabaseAgent(query: string): Promise<string> {
    return queryDatabase(query);  // Direct function call
}

Viewing the Results

After running your agent, AgentGraph seamlessly handles the complete interaction flow:

Automatic Tool Orchestration: When the LLM decides to invoke a tool, callLLMWithToolHandling automatically executes the corresponding tool implementation and feeds the result back to the LLM for further processing.
Complete Trace Capture: Every interaction, tool call, and response is captured and saved to ./agentgraph_output/${sessionId}.json, creating a comprehensive execution trace.
Interactive Visualization: The generated JSON file can be visualized using the AgentGraph visualizer, which renders your agent interactions as an interactive graph.

The visualization provides:

Chat Flow: LLM interactions as conversation bubbles
Tool Calls: Expandable sections showing tool inputs and outputs
Nested Agents: Subgraphs for tools that use LLMs internally
Execution Flow: Clear visual representation of the decision-making process

This integration approach provides complete visibility into your multi-agent system without requiring significant changes to your existing code structure.

Take away

As AI agent systems become increasingly sophisticated, the ability to understand and debug their behavior becomes crucial for reliable deployment. AgentGraph addresses this challenge by providing real-time visualization of multi-agent interactions, making complex decision flows transparent and debuggable.

Key benefits of using AgentGraph include:

Zero-friction Integration: Minimal code changes required to instrument your existing agent systems
Complete Visibility: Track every LLM interaction, tool call, and nested agent execution
Interactive Debugging: Visual graph interface that lets you drill down into specific interactions
Multi-language Support: Works seamlessly with both Python and Node.js backends
Session Management: Automatic trace capture and file generation for analysis

Whether you're building simple tool-calling agents or complex multi-agent orchestration systems, AgentGraph provides the observability you need to understand, debug, and optimize your AI workflows.

Check out the AgentGraph repository and give it a ⭐ if you find it useful! Your support helps me continue developing tools that make AI development more transparent and accessible.

DEV Community: Rishabh Poddar

Human-in-the-Loop AI Agents: Approvals, Permissions, and Audit Trails

What human-in-the-loop AI actually means

Why approvals matter

Why permissions matter even more

What an audit trail should record

The common failure mode

A better pattern for teams

What this means for product teams

Where this leaves the market

FAQ

What is human-in-the-loop AI?

Is human-in-the-loop AI the same as human oversight?

Do all AI actions need human approval?

What kinds of actions should usually require approval?

Why are permissions important if I already have approvals?

What should an audit trail include for AI agents?

Can human-in-the-loop slow teams down?

How is teamcopilot.ai relevant here?

What is the biggest mistake teams make with agent approvals?

What is the simplest way to start?

Claude in Slack Explained: What Claude Tag Can Do, Benefits, and Downsides

What Claude Tag is

What it can do well

1. Work where the conversation already happens

2. Keep shared context in public view

3. Handle repetitive coordination work

4. Add proactive behavior

Where it gets awkward

1. Slack is a constraint, not just a feature

2. Shared memory is useful and risky

3. Permissions get complicated fast

4. Token cost is a real concern

5. It can feel too tied to one vendor and one model

Where teamcopilot.ai fits

A practical read on the launch

Related reading

FAQ

Is Claude Tag the same as Claude in Slack?

What is the main benefit of Claude Tag?

What can Claude Tag actually do?

Is Claude Tag only for engineers?

What are the biggest downsides?

Is Claude Tag safe for sensitive company data?

Why do people worry about token usage?

Could Claude Tag replace a workflow platform?

When should I choose teamcopilot.ai instead?

Who should choose Claude Tag versus teamcopilot.ai?

Should I use both?

What should I watch out for before rolling out a tool like this?

How should a team make the final decision?

MCP vs Skills: Why Skills Save Context Tokens

The hidden cost of always-on MCP

Why skills are cheaper

Skills can replace the MCP layer

A simple rule

What this looks like in practice

How to convert MCP into a skill

A good pattern for teams

The real goal: less context waste

Related reading

FAQ

Is MCP bad?

Do skills replace MCP?

Why do skills save tokens?

What kind of content belongs in a skill?

What kind of content belongs in MCP?

Can I keep both MCP and skills for the same service?

Why use mcpview.teamcopilot.ai?

What if the MCP spec changes?

What is the best short description for a converted skill?

Sakana AI's Fugu Explained: How the Multi-Agent Model Orchestrates Frontier LLMs

What Fugu actually is

How it works

Why the orchestration layer matters

Fugu versus Fugu Ultra

What the benchmarks suggest

The product details that matter

Why this is a bigger product than it looks like

Where teamcopilot.ai fits

Should Claude Code be allowed to read `.env` files?