Acceptance criteria, checked
Write what success means before the work starts. Every acceptance criterion must be ticked before completion can pass.
Everything in Seyal serves one rule.
Work reaches Done only with proof. These are the parts that make that rule hold, from the first request to the last approval.
One way to Done
A task reaches Done through one completion check, wherever the request comes from.
Required evidence, attached
Keep pull requests and verification results with the task. The check requires each evidence kind specified for that task in its required state.
Approval of this version
A person approves the exact task version. If the task changes, that earlier approval becomes stale and a fresh review is needed. Follow the task through the check.
Protected and sensitive changes
Some changes always need a person, whatever an agent may do: auth, permissions, payments, migrations, CI or deploy, dependencies, production data and business decisions. A pull request that touches protected files, such as CI definitions or agent control files, needs an owner's approval and checks Seyal can trust.
Agents as workers, not owners
Give an agent context and a claim on the work. Keep decisions and review with people.
MCP built in
The server exposes task tools at /mcp over Streamable HTTP. Connect Claude Code, Codex or another MCP client with its own token. A member's token is limited to the projects they choose.
Claim before starting
One live claim identifies who is working on a task. Progress reports renew the claim; silence makes it stale after five minutes.
PRs and evidence
Your coding agent opens a pull request in your repository and uses link_pr to attach it as evidence in Seyal. With GitHub or Azure DevOps connected, commits that name a task key log progress, opening a PR moves the task to In review, and a merge moves it to Verify, never directly to Done.
People retain control
Seyal agents never merge or delete. External repository permissions remain yours to manage. Set up agent access.
Full history
Keep the trail with the work, from the first claim to the completion check.
Changes become events
The task service writes an event in the same transaction as each change. The change and its history stay together.
See who did what
Task history identifies the actor, event and time. Named client tokens distinguish one coding client from another.
Trace review decisions
Approvals refer to task versions, so you can follow the decision back to the work that was reviewed. Read an example history.
Watch the run
An agent posts its plan and reports each step as it starts and ends. The task shows the live steps, a flow diagram and the run's stage, from intake to merged. A Claude Code hook can also report which files and todos it touched, never their contents.
Built-in agents and reminders
Use server-run help for planning and follow-up, with the settings under your control.
Triage and planning
The triage agent suggests where incoming work belongs. The planner proposes subtasks, acceptance criteria and an estimate.
Review and briefings
Seyal picks PR reviewers from each task's risk and areas, and each files a verdict on the current version. Built-in agents also prepare decision memos, write release notes and produce a daily brief. AI features use the provider and permissions configured for your installation.
Reminders and follow-up
Set reminders for yourself. Scheduled jobs fire due reminders, while follow-up and risk watchers surface work that needs attention.
Choose the autonomy
Agent settings control whether suggestions wait for approval or apply automatically where supported. All task changes still use the task service. Routines lists each scheduled job, with a pause switch and a daily cap. Meet the built-in helpers.
Work in from anywhere
Capture a request, then decide which project and task it should become.
The web app
Create and manage work in the browser. The board, task details and triage inbox share the same task service as MCP clients.
Email into triage
With a Microsoft 365 intake mailbox and app credentials configured, Seyal polls mail into the triage inbox. A person can review and place each request before it becomes project work.
Agent-created requests
MCP clients can create a task in a named project. Without a project, create_task puts the request in the triage inbox for a person to place.
Ask Seyal
Ask questions about the board from a panel on every page. Once Ask has read board text, each change it proposes waits for you to confirm it.
Organise the work
Give each project a home, and keep a view across the whole team.
A board for the work
Follow tasks through the workflow, including In review, Verify and Done. Open a card to see its criteria, evidence and history. Link tasks as blocking or related; a task waiting on unfinished work shows Blocked.
Projects and subprojects
Group related work beneath a root project with one level of subprojects. Each subproject keeps its own key, board and settings.
An all-projects view
See work across projects on one board, with cards grouped by project within each status. Narrow the view when you need to focus. The Map shows tasks, runs, skills and routines, and what needs you.
Settings in one place
Manage appearance, notifications, MCP access, connections, team standards, sensitive changes and project settings from Settings. Scope labels show whether a setting affects you, the team or a project.
Yours to run
Keep Seyal records on infrastructure you control and choose which integrations to connect.
Self-hosted
Run the app and Postgres on your own server. You manage access, backups and updates. Read the self-host guide.
AGPL-3.0 at launch
The source is not public yet. AGPL-3.0 is the announced licence at publication; there is no announced publication date.
Try it with sample data
The demo runs the real web app with fictional workspace records and needs no account. Changes stay in memory and reset on reload. Open the demo.
Take your work with you
Owners can export the event log, a full JSON export, and an Obsidian vault of team standards, project context and tasks as linked Markdown notes.