One loop,wherever the work starts.

Echelar is a team of AI agents anyone on your team can call from Slack, GitHub, Linear, or Echelar's own app — or put on schedules as Automations. Every job ends the same way: a result a person approves.

Where it runs

Work starts wherever the signal already lives. The loop that follows is the same.

SurfaceWhat happens
SlackMention Echelar in an enrolled channel. It investigates or builds, and the result returns to the thread.
GitHubInstall the GitHub App. Echelar reviews pull requests after CI passes and answers when you mention it in a pull request thread.
LinearAssign an issue to Echelar. A Session works it, and the pull request attaches back to the issue.
The Echelar appChat with it, watch live activity, and manage Automations.
SchedulesRecurring Automations on your schedule. When the work changes code, a pull request comes back. Nothing merges.

The four steps

Every job — a Slack mention, an assigned issue, a scheduled Automation — moves through the same four steps.

  1. You call it

    From Slack, GitHub, Linear, the Echelar app, or a schedule — work starts where the signal already lives.

  2. Its agents do the work

    In an isolated sandbox, grounded in how your repository actually works: its architecture, decisions, and conventions.

  3. It hands back a pull request

    With the evidence attached — activity, changed files, checks, and artifacts your team can inspect.

  4. Someone on your team approves and ships

    A person reviews the result, decides what ships, and performs the merge.

There is no merge button. We didn't build one.

Automations

An Automation is a versioned definition of when work starts, where it may run, and what must come back to a person.

Describe one in plain English and Echelar drafts it. Every draft lands disabled until a person enables it.

Before you enable an Automation, we can dry-run it with you against a real recorded event and show exactly why it would or wouldn't fire. Once it is enabled, every fire writes an audit record with the prompt it sent.

Standing orders

One request in a Session. One disabled draft. One Monday pull request.

Describe the recurring job in a Session. Echelar drafts the schedule, scope, checks, and Reviewer handoff, and the draft stays disabled until an authorized person enables it. On Monday at 08:00 the Automation starts and comes back as pull request #88, waiting for review.

Demonstration — authored data · human review before enablement
Starts when visible

Sequence description

  1. A teammate asks for a weekday Automation that repairs the slowest checkout-api spec.
  2. Echelar loads the repository architecture, test conventions, and required checks.
  3. The Session inspects recent test timing and identifies the slowest stable spec.
  4. Echelar drafts the schedule, scope, pull-request delivery, and Reviewer handoff.
  5. The Automation definition is validated against repository capabilities and approval rules.
  6. A disabled Automation draft appears for human review.
  7. A person on the team reviews the definition and explicitly selects Enable Automation.
  8. The enabled Automation is attributed to Mouna and waits for its next scheduled start.
  9. Monday 08:00 arrives and the schedule starts the Automation.
  10. A Session repairs the slowest spec in acme/checkout-api and checks the suite.
  11. Pull request 88 arrives for review, and the audit record ties it to the Automation, its version, and the Monday start.

How it improves

Echelar keeps organization-scoped memory that is demoted automatically when the code it describes changes.

Repeated review corrections can become versioned Skill drafts — disabled, with the evidence cited — that a person reads and enables.

Enabled changes affect future Sessions only.

Repository learning recordAuthored · billing-api · three reviewed outcomes
First correction retained
Reviewed outcomesSame correction · 3 matches
  1. Session 184
    Migration guard missingReviewer finding
    repo@7f31c2PR #842
  2. Automation 071
    Migration guard missingReviewer finding
    repo@81a0bcPR #901
  3. Session 193
    Migration guard missingReviewer finding
    repo@8a44e1PR #918
Proposed improvementProposed as draft · disabled
skill / v3

Billing 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
Priya enabled v3Human review · August 14
Future SessionsBilling work loads Skill v3 with the current repository context.enabled revision only

Bring one repository.

Book an intro and we'll walk this loop on your code — where work starts, what comes back, and who approves it.