Why we're building Linestop

Status. Linestop is in development. Nothing in this post is live today. Every capability described here is Planned: designed, not built yet.

Technical work rarely fits in one tool or one pass.

A customer reports a bug, and the report is thin. Someone has to work out what is missing. Someone has to ask the customer. Then the bug needs a clear write-up, a patch and a test.

An incident starts with an alert. One pass rarely finds the cause. One person investigates, another adds what they know, and the investigation runs again with the new facts.

A pull request opens. It needs a review, and the findings need to reach the people who can act on them.

These are different kinds of work. They use the same parts: people, agent reasoning, actions, evidence, waits and iteration. We think that shared model is the product.

What we’re building (Planned)

We’re building Linestop as a platform for running technical work across people, agents and tools. Your team defines a workflow. The workflow carries the work through agents, automated actions, people, waits and loops with limits you set.

In the three cases above, it would work like this:

• Customer bug refinement. An agent investigates a thin report and lists what is missing. A person adds context. The agent writes a refined bug report. A patch is written and tested.
• An incident that loops through people and agents. An agent investigates the alert. A person adds findings or takes over. The agent investigates again. You set how many times it may loop.
• Pull request review. An agent reviews a pull request and stores its findings. A separate step publishes them as a comment.

Where the Jira part comes from

I have worked in organizations (and have friends in similar organizations) where changing a workflow in Jira meant filing a ticket with an administrator or tool owner. The tickets were painful. So was editing and versioning those workflows. So no one uses them.

That is my experience. It is not a measurement, and I don’t know how common it is. Jira also has team-managed spaces, where a space administrator can edit workflows, and a delegated permission to edit workflows in some cases. Other tools, including ServiceNow, Windmill and n8n, already support Git-based development.

So Git alone is not the idea. What I want to find out is whether the whole experience can be better for the engineers who own the work: how a workflow is written, changed, tested and operated. We haven’t measured that. We won’t claim faster changes or less administration until we have.

Your team owns the workflow (Planned)

This is the direction. 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 a sensitive step, needs the right permission.

The design is not finished. We haven’t settled how the UI and the repository stay consistent, who owns what, or how a step is marked as sensitive. The first version we’re planning is simpler: a YAML editor that validates your workflow, and forms to connect GitHub. That first version does not include the Git-backed authoring described above.

Where we are

Nothing is live yet.

We’re looking for engineering teams who work in GitHub and want to shape this with us. If that’s you, explore a design partnership.