Skip to content
Linestop

Run technical work across people, agents and tools.

We're building Linestop so your team can define how features, customer bugs, incidents and operational requests get done. Connect investigation, human collaboration and permitted actions in workflows you can inspect and change.

Start from a template or describe your own process. Decide where people contribute, what agents may do and how the result is checked. Planned

Explore a design partnershipGet product updates

In development. We're building it to run our own work.

Planned
Designed. Not built yet.

The same platform, different kinds of work

Technical work rarely fits in one tool or one pass. These are three examples of what we're building Linestop to run. They are examples, not the whole product.

Customer bug refinement

Planned

A customer reports a bug, and the report is thin. We're building a workflow that gets it to a tested fix.

  1. An agent investigates the report and lists what is missing.
  2. A person adds context or asks the customer.
  3. The agent writes a refined bug report.
  4. A patch is written and tested. The fix follows the steps you define.

An incident that loops through people and agents

Planned

One pass rarely finds the cause of an incident. We're building a workflow that investigates, asks for human input, then investigates again.

  1. An agent investigates the alert.
  2. A person adds findings or takes over.
  3. The agent investigates again with what was learned. You set the limits on how many times.
  4. The workflow can take an action or page someone. It ends with a report and a postmortem.

Pull request review, the first workflow we'll run on our own work

Planned

This is the workflow we're building to run on our own repositories.

  1. A pull request opens. An agent reviews it and returns findings as a stored report.
  2. A separate step publishes the findings as a comment on the pull request.
  3. You can inspect or revise the findings, or publish them again, without rerunning the review.
  4. If you want a person to check the findings first, you add that step.

Also on our list

Planned

We're also designing for product-limit change requests and for capacity changes. One example: database CPU pressure leads to an infrastructure change, a person approves it, then it is applied. Each needs a real connection and clear authority before we say it works.

What the examples share

Every example uses the same parts: people, agent reasoning, actions, evidence, waits and iteration. That shared model is the product.

How it works

  1. Define the workflow.

    Write it in YAML in an editor that validates it. Connect GitHub with a form. Planned

  2. Place people and agents as steps.

    If you place an agent step, the agent acts. If you place a human step, a person acts. There is no hidden default. A review is a step you add. Planned

  3. Inspect every run.

    See which step ran, who or what acted (a person, an agent or a connection) and what changed. Planned

Your team owns the workflow

We're building Linestop so your engineers can change workflows in the UI or in YAML, backed by Git, with branches and tests. Routine changes stay with the team that owns the work. Giving an agent new tools or permissions, or changing sensitive steps, needs the right permission. Planned

Agent calls run on your own model account

You use your own account with a model provider for agent calls, and pay the provider directly. We don't resell tokens. We plan to support Anthropic, OpenAI and other major providers, such as Amazon Bedrock and OpenRouter. See Pricing and Security. Planned

Bring us a process

We're looking for engineering teams who work in GitHub and want to shape this with us.

Explore a design partnershipGet product updates