A team of AI agents, on call in Slack, GitHub, and Linear.
Ask Echelar to investigate an incident, fix a bug, review a pull request, or update the docs. Its agents do the job in an isolated sandbox, grounded in how your codebase works, and hand the result back where you asked.
Nothing merges itself. Nothing enables itself. Every action is audited.
CheckoutRetryError crossed the production threshold after the latest release. Can you find the cause before we roll back?
Demonstration on a fictional Acme repository — authored data and timings.
Code got faster.
Delivery didn't.
Every fix, report, and small change still sits in Slack or the backlog, waiting for the two people who know that subsystem.
A copilot suggests a change. The rest of the job is still yours:
LOCALStill yours Run itPull the branch. Reproduce what the AI claims.
CIStill yours Test itWait for the pipeline. Read the failures.
PATCHStill yours Fix itRepair what broke, again.
REVIEWStill yours Review itRead every line nobody fully trusts.
MERGEStill yours Ship itOwn the call, and the pager.
Echelar closes that loop.
One governed path, wherever the work starts. Every demonstration on this page follows it.
- 01Signal
You call it.
Mention it in Slack, assign it a Linear issue, open a pull request, or set a schedule.
- 02Sandbox
Its agents do the work.
In an isolated sandbox, grounded in your repository's architecture and conventions. Watch every step live.
- 03Evidence
It shows its work.
A pull request comes back with evidence: what changed, what was checked, what the checks said at that exact commit.
- 04Decision
Your team decides.
Merge, request changes, or close it. Echelar has no merge button. We didn't build one.
Pick the job that's eating your week.
Five jobs, one team of agents. Each has its own page and a full demonstration.
Turn an incident into a fix
An error lands in Slack. Echelar investigates, posts a cause and a recommendation, and writes the fix on your go-ahead.
Read the full storyStarts in GitHubReview every pull request
Once CI passes, the Reviewer reads the pull request against your architecture and files findings by severity. It reads code; it never writes it.
Read the full storyStarts when main changesKeep docs true to the code
Docs checked against the exact commit they describe. Green when the shipped revision passes, not when a pull request opens.
Read the full storyStarts in LinearTicket in, pull request out
Assign Echelar a Linear issue. Watch the Session work. The pull request comes back attached to the issue.
Read the full storyStarts on a schedulePut recurring work on a schedule
Say what needs doing and how often. The pull request arrives on schedule; nobody has to remember.
Read the full storyWork that starts without you.
Describe the recurring job in plain English. Echelar drafts the Automation: trigger, scope, checks, and where the result goes.
Sweep dependencies weekly. Re-sync docs nightly.
The same four steps, on a timer. When the job changes code, it comes back as a pull request.
Alert posted. Pull request opened. Tag pushed.
Automations fire from what already happens in your tools. No new dashboard, no new process.
Versioned. Audited. A person enables it.
Every fire leaves an audit record with a match trace and the exact prompt it sent. Any version can be rolled back.
Named agents. Named limits.
Not one chatbot: a team with roles, and every role has something it can never do. That column is the product.
| Agent | What it does | What it can never do |
|---|---|---|
| Orchestrator | Takes your request, plans the work, and hands it to the specialists. | Enable anything. Every Automation or Skill it drafts lands disabled. |
| Incident Commander | Investigates an alert against the code, recent changes, and its own sandbox; posts a cause and a recommendation. | Change code before a person says go. |
| Technical Lead | Plans the technical approach and checks the Builder's work inside the Session, against how the repository already does things. | Merge, enable, or widen the scope without a person. |
| Builder | Implements the change in an isolated sandbox, the way the repository already does things. | Touch production or merge. The result is a pull request. |
| PR Reviewer | Reads each pull request against your repository and files findings by severity. | Write code or merge. A fix is a separate Session a person starts. |
Specialists work behind these — Explorer, Browser, and the Reflector that drafts a Skill when your team corrects the same thing twice. The product lists every agent and its version per repository.
We build Echelar with Echelar.This team works our own repositories every day, under the same limits.
It gets better on purpose. Never in secret.
When your team corrects the same thing twice, Echelar drafts the fix as a versioned Skill: disabled, evidence cited. When the code under a memory changes, the memory is demoted.
- Session 184Migration guard missingReviewer finding
repo@7f31c2PR #842 - Automation 071Migration guard missingReviewer finding
repo@81a0bcPR #901 - Session 193Migration guard missingReviewer finding
repo@8a44e1PR #918
skill / v3Billing migration guard
Require a rollback path and verify schema compatibility before a billing migration returns for review.
- Source
- 3 reviewed outcomes
- Scope
- Billing module
- Revision
- Skill v3
enabled revision onlyThe questions worth asking first.
What can Echelar write to?
A branch in an isolated sandbox, and the pull request it opens from it. Merge, deploy, and enabling an Automation are actions that exist only for people; there is no capability for an agent to perform them.
What do we need to start?
The GitHub App on one repository, Slack or Linear connected, and your own model keys, stored encrypted. The first real alert or ticket is the test.
Does it work with our stack?
Anything that posts to an enrolled Slack channel can start an investigation, and the sandbox uses your repository's own environment definition. Echelar works from the alert, the code, and its history — it does not need access to your observability tools.
Where does our code run?
On Echelar's control plane, in an isolated sandbox per Session, scoped to your organization. Not inside your infrastructure. The security page has the exact answers.
How do we stop it mid-task?
Every Session is live: tool calls, changed files, checks. Reply, or close it. Code stays in the sandbox until it returns as a pull request.
What does it cost?
Echelar is launching now. Early teams work directly with the founder and agree pricing together.
Granting repository access is a serious question.
Here are serious answers: where code runs, who can enable what, and what we don't claim.
- An isolated sandbox per session, scoped to your organization.
- Your own model keys, stored encrypted. Per-organization GitHub tokens.
- Per-organization roles and a full audit trail.
- Data stays organization-scoped. Nothing is pooled across customers.
Bring the repository you'd never trust to a demo.
Not the toy repo. The one held together by tribal knowledge. We'll point Echelar at it live. You watch what it reads, what it does, and where it stops to ask.