// FIELD NOTE
Detent vs Hyperagent

Cory LaNou

Detent vs Hyperagent
Overview
Hyperagent and Detent sit close enough together that people are going to compare them, but they are not trying to be the same thing. Hyperagent gives you hosted agent teammates that can work across SaaS tools, channels, schedules, and artifacts. Detent gives you a self-hosted workflow runtime that turns issues, gates, review rules, isolated worktrees, and a merge train into the system that keeps work moving. One is hosted convenience with broad integration reach. The other is control, reproducibility, and discipline around the work contract.
That makes this a useful comparison, not a fight.
The short version
If your problem is recurring cross-SaaS business work, Hyperagent is easy to understand. You configure an agent once, give it tools and knowledge, let it show up in Slack or email or a schedule, and collect the finished output in a Library.
If your problem is "I have real engineering work, with acceptance criteria, tests, reviews, CI, and merge ordering, and I want many agents moving safely at once," Detent is a better shape. Detent is not trying to be the teammate. Detent is the operating system for the work.
That distinction is the whole post.
What Hyperagent is
Hyperagent is Airtable's hosted agent platform. Hyperagent's own site does not make the ownership relationship the main headline, but Browserbase's case study is explicit: it describes "Hyperagent by Airtable" and quotes Airtable leadership talking about the product direction.
The product model is agent-first. In Hyperagent's docs, an agent is a persistent colleague: a configured teammate with a role, tools, context, and invocation methods that carries the same setup across conversations and triggers. The agent can have identity, tools and integrations, skills, knowledge, model and budget controls, approval behavior, delegation settings, and invocations from threads, Slack, Telegram, schedules, webhooks, email, and Live Mode.
That is a good mental model for the thing Hyperagent is good at: persistent business agents that own recurring responsibilities. A RevOps agent watches pipeline movement. A Chief of Staff agent drafts updates. A Customer Success agent tracks account health. The agent is the named actor.
Hyperagent also has an artifact model. Its Library is where generated work lands: documents, tables, webpages, slides, images, maps, HyperApps, uploads, exports, PDFs, CSVs, code files, and other files. You do not have to dig through the whole conversation to find the thing the agent made.
That is a strong hosted workflow product. I would not pretend otherwise.
What Detent is
Detent is a different category. It is free, open source, self-hosted work orchestration, with code as the first proven domain.
The important sentence is still this: Detent is a system, not an agent.
You do not configure Detent as a teammate and ask it to remember your preferences. You write a work contract. The contract lives in the issue, the acceptance criteria, the labels or board statuses, the WORKFLOW.md, the validation gate, the review policy, and the merge rules. Detent watches the work, claims ready issues, creates isolated worktrees, dispatches an agent, runs the gate, opens or updates the pull request, and moves the issue through the workflow.
The agent is replaceable. The workflow is the durable thing.
That is why Detent cares so much about isolation and merge discipline. Multiple issues can move in parallel because each one gets its own worktree and branch. Finished work does not stampede main because the Merging lane is serialized. One issue rebases, watches current-head CI, and merges before the next one starts. The board is not just a pretty view. It is the state machine.
Detent's bet is that the intelligence should live in the spec and the runtime should supply discipline.
The real tradeoff
Here is the comparison I would actually use when choosing between them.
| Question | Hyperagent | Detent |
|---|---|---|
| What is the product shape? | Hosted agent teammate platform | Self-hosted workflow orchestration system |
| Who is the actor? | The configured agent | The issue/work contract |
| Best fit | Cross-SaaS business workflows | GitHub-native engineering workflows |
| Source of truth | Hyperagent workspace, threads, agents, Library | GitHub issues/status, PRs, workflow gates, merge rules |
| Invocation model | Slack, Telegram, email, webhooks, schedules, Live Mode, threads | Tracker status changes and workflow state transitions |
| Output model | Artifacts in a hosted Library | Branches, PRs, validation evidence, merged work |
| Infrastructure | Hosted SaaS | Self-hosted single Go binary |
| Model strategy | Platform-managed model choices and controls | Bring your own agent/model path, including local options such as Ollama where your workflow supports it |
| Cost shape | Hosted usage/platform cost | No Detent platform fee; you still own model, compute, and infrastructure costs |
| Control boundary | Convenience and managed integrations | Reproducibility, auditability, air-gappability, and local policy control |
The tradeoff is not "good versus bad." It is hosted reach versus owned process.
Hosted reach is powerful. If you want one agent to operate across Gmail, Calendar, Slack, Notion, Airtable, Databricks, GitHub, and whatever else your business runs on, a hosted integration platform has a real advantage. You get distribution, authentication, hosted execution, managed browsers, and a product surface built for non-engineering teams.
Owned process is powerful too. If you care about exactly what branch was created, what prompt was used, what issue defined done, what tests ran, what review gate passed, what CI commit was merged, and whether ten agents can finish without invalidating each other, you want the runtime close to your repo and your rules.
That is Detent's lane.
Where hosted integrations bite
The hosted-integration tradeoff is not theoretical. In May 2026, Composio disclosed a third-party security incident. Hyperagent used Composio to facilitate integrations between Hyperagent and third-party data sources, and Hyperagent published a detailed response on May 23, last updated May 26.
Their response was the right kind of response: public timeline, customer notification, token guidance, all Composio-powered integrations disabled, token revocation checks where possible, and first-party integrations shipped for the most important services. I am not bringing it up to dunk on them. They handled it transparently.
I am bringing it up because it illustrates the tradeoff.
When a hosted agent platform gives you a wide integration surface, it has to hold or broker credentials somewhere. It has to depend on other hosted integration systems somewhere. That is the price of "connect everything and start working." A good vendor can reduce that risk, respond fast, and be honest when something happens. Hyperagent did that.
But if your requirement is "this must run under my control, with my credentials, my network boundary, my workflow, and no platform dependency," then the answer is not a better hosted teammate. The answer is self-hosted orchestration.
That is exactly why Detent exists.
The difference is where intelligence lives
Hyperagent makes the agent durable. You give the agent a name, role, skills, knowledge, tools, controls, and trigger points. The durable artifact is the teammate configuration.
Detent makes the work durable. You give the issue acceptance criteria, the workflow a gate, the project a merge policy, and the runtime a state machine. The durable artifact is the contract for moving work from idea to done.
That difference changes the way the system behaves.
With Hyperagent, I would expect to ask: "Which agent owns this responsibility?" With Detent, I ask: "What is the definition of done, and which gate proves it?"
With Hyperagent, I would expect work to start from a message, schedule, webhook, or thread. With Detent, work starts when an issue enters the ready lane.
With Hyperagent, the Library matters because the output is an artifact produced by an agent. With Detent, the PR matters because the output is a tracked change that must survive review, CI, and merge ordering.
Again, both are coherent. They are coherent in different directions.
The name is confusing
One sidebar because this will trip people up: there are several unrelated things called Hyperagent or HyperAgent.
The one in this post is hyperagent.com, Airtable's hosted agent platform.
That is not the FSoft-AI4Code HyperAgent paper, "HyperAgent: Generalist Software Engineering Agents to Solve Coding Tasks at Scale." That paper is about a generalist software engineering multi-agent system with planner, navigator, code editor, and executor roles.
It is also not Meta's 2026 Hyperagents paper, which is about self-referential agents that combine a task agent and a meta agent into an editable program for self-improvement.
Three unrelated things share the name. If you are reading benchmarks, papers, or product docs, check which one you are actually looking at.
What I would use each for
I would use Hyperagent for business workflows where the agent needs to live across SaaS systems and produce reusable artifacts for a team:
- Weekly account-health summaries
- Lead research tables
- Leadership updates
- CRM hygiene
- Scheduled reporting
- Cross-tool operations work
I would use Detent for work where the unit of work is an issue and the output has to pass a deterministic delivery path:
- Code changes across many repos
- Documentation changes that need review gates
- Content production that ends in a PR
- Refactors with clear acceptance criteria
- Parallel maintenance work
- Any workflow where merge ordering and validation evidence matter
The more your work looks like a recurring business responsibility, the more Hyperagent makes sense. The more your work looks like a controlled delivery pipeline, the more Detent makes sense.
The honest Detent pitch
Detent is not the easiest way to get an agent into Slack. It is not trying to be.
Detent is for the moment after you realize the hard part was never getting one agent to do one task. The hard part is running many pieces of work at once without becoming the human scheduler, reviewer, conflict resolver, CI watcher, and merge coordinator.
That is the part Detent takes seriously:
- Free and open source
- Self-hosted
- GitHub-native
- Issue-driven
- Isolated worktrees
- Bring-your-own agent and model path
- Local-model-friendly where your workflow supports it
- Validation gates you control
- Human review when you want it
- Deterministic serialized merge train
- No platform fee for the orchestration layer
That last point matters, but it should be stated honestly. Detent being free does not make AI free. You still pay for the model, the machine, and whatever services your workflow calls. What you do not pay is a platform tax to run the orchestration system.
The takeaway
Hyperagent is a hosted agent teammate platform. If you want persistent agents that work across SaaS systems and produce artifacts for a business team, that is a good product shape.
Detent is self-hosted workflow orchestration. If you want issues, acceptance criteria, gates, PRs, CI, review policy, isolated worktrees, and a serialized merge train to become the system that manages agents for you, that is a different product shape.
The future probably has both categories. Hosted agent colleagues will be great for broad business automation. Self-hosted workflow orchestration will be necessary anywhere control, reproducibility, auditability, and deterministic delivery matter.
I built Detent for the second category. I do not want to manage agents. I want to manage work.


