Skip to main content

Agentic Board

An MCP-driven ticket platform where coding agents claim, analyse, implement and test work, with linked evidence and a human quality gate.

At a glance

Project type
Prototype
Year
2026
Project stage
Active
Role of 5A Technologies
Co-development with Infium, agentic architecture, MCP workflow design, quality gates and product implementation.
Technologies
  • TypeScript
  • Next.js
  • React
  • Node.js
  • PostgreSQL
  • Redis
Agentic Board — controlled agentic delivery flowHover or focus for details. On mobile, tap a phase to open it.

Ten-phase Agentic Board workflow turning plans into MCP tickets, board context and priorities before agent analysis, implementation, QA, pull-request sync and human review. 1. Structure the plan: Functional, technical, security and QA input 2. Build tickets through MCP: Phases receive scope, criteria and dependencies 3. Connect board context: Sprint, team, repository and agent pool 4. Weigh and prioritise: Value, risk, permissions and dependencies 5. Make ticket executable: Scope and criteria are ready for claiming 6. Agent claims ticket: A suitable permitted task is locked 7. Analyse context and code: Approach, risks and blockers are identified 8. Implement and validate: Code, tests and required checks 9. Synchronise PR and board: Evidence, status and PR remain linked 10. Human quality gate: Approve, rework, reject or block Connections: Structure the plan to Build tickets through MCP (structured plan). Build tickets through MCP to Connect board context (tickets with criteria). Connect board context to Weigh and prioritise (board and project context). Weigh and prioritise to Make ticket executable (weighted executability). Make ticket executable to Agent claims ticket (permitted ticket). Agent claims ticket to Analyse context and code (locked assignment). Analyse context and code to Implement and validate (bounded approach). Implement and validate to Synchronise PR and board (code, tests and evidence). Synchronise PR and board to Human quality gate (review-ready pull request). Human quality gate to Analyse context and code (changes requested). Synchronise PR and board to Make ticket executable (next permitted ticket).

Agentic Board · system flow10 phases · human quality gate and rework
  1. Structure the planFunctional, technical, security and QA input
    Plan, executable ticket and claimA plan is divided into executable parts

    Functional, technical, security and QA input remains the source for scope, acceptance criteria and quality requirements for every phase and subphase.

  2. Build tickets through MCPPhases receive scope, criteria and dependencies
    MCP, board context, prioritisation and board syncThe ticket factory creates a controlled execution contract

    Every executable part receives scope, acceptance criteria, dependencies, sprint, repository, risk, evidence requirements, allowed actions and review policy.

  3. Connect board contextSprint, team, repository and agent pool
    MCP, board context, prioritisation and board syncProject context and access are connected to the ticket

    Board, Wiki and Test Plan provide relevant project rules, repository context, test requirements, permissions and available runner capabilities.

  4. Weigh and prioritiseValue, risk, permissions and dependencies
    MCP, board context, prioritisation and board syncNot every ticket is executable at every moment

    Priority, weight, dependencies, repository, risk, permissions and runner capabilities determine which work can be taken on responsibly.

  5. Make ticket executableScope and criteria are ready for claiming
    Plan, executable ticket and claimThe ticket connects planning, execution and review

    An executable ticket forms the fixed agreement between the original request, agent actions, required quality evidence and human assessment.

  6. Agent claims ticketA suitable permitted task is locked
    Agent analysis, implementation and QAClaiming prevents simultaneous execution of the same work

    A suitable runner claims one permitted ticket. Locking and idempotency bound duplicate execution and keep ownership and status visible on the board.

  7. Analyse context and codeApproach, risks and blockers are identified
    Agent analysis, implementation and QAThe agent examines the assignment before implementation

    The runner analyses permitted repository context, dependencies, acceptance criteria, risks and missing information and records a bounded approach.

  8. Implement and validateCode, tests and required checks
    Agent analysis, implementation and QAChanges and quality evidence are created in a bounded workspace

    The agent makes the change and runs required build, test, security and accessibility checks. An unresolved blocker remains explicitly visible for human input.

  9. Synchronise PR and boardEvidence, status and PR remain linked
    MCP, board context, prioritisation and board syncThe ticket receives the controlled execution result

    Commits, checks, evidence, remaining risks and the pull-request reference are linked to the same ticket and the original acceptance criteria.

  10. Human quality gateApprove, rework, reject or block
    Human quality gate and reworkA reviewer decides what happens to the change

    A person can approve, request targeted changes, reject or block. Merging, deployment, release and closure happen only when configured policy explicitly permits each action.

Plan, executable ticket and claimMCP, board context, prioritisation and board syncAgent analysis, implementation and QAHuman quality gate and reworkAgentic Board links planning, ticket context, agent execution, evidence and review; rework and ticket selection use separate feedback loops.

After board sync, a runner can take another permitted ticket while review remains active separately.

Merging, deployment, release and closure remain subject to explicitly configured policy.

Claiming, idempotency and locking prevent runners from executing the same ticket simultaneously.

A blocker requires human context, access or an external decision.

In brief

Agentic Board is a shared ticket platform for human teams and authorised coding agents. Functional and technical plans are converted through Model Context Protocol into structured tickets with scope, acceptance criteria, dependencies, risk, permissions and review policy.

A suitable runner can claim an allowed ticket, analyse the repository, implement a change, run quality checks and link a pull request. Ticket status, evidence and review decisions remain attached to the same assignment. A human quality gate determines what is approved, reworked, rejected or blocked.

Agentic Board is a joint initiative by 5A Technologies and Infium. A proof of concept is used in a limited private pilot. The broader public product release remains in development.

  • Context: shared software delivery for human teams and authorised coding agents
  • Project: joint initiative by 5A Technologies and Infium
  • Status: proof of concept in a limited private pilot; broader public product release in development
  • Role of 5A Technologies: agentic product and workflow architecture, ticket model, lifecycle, synchronisation and human quality gates
  • Core principles: bounded tickets, controlled agent execution, quality evidence and human decision-making

Important design principle

An agent receives a bounded assignment and permitted actions. Merging, deployment, release and closure remain separately subject to the configured policy and human quality gate.

The problem

Without a shared structure, agentic software work becomes fragmented:

  • assignments remain scattered across chats, issues and isolated prompts;
  • agents can miss project context or dependencies;
  • several runners can claim the same work;
  • code, tests, evidence and review decisions become disconnected.

Agentic Board turns those separate interactions into one traceable delivery flow. The board remains the central work queue, while the ticket forms the agreement between planning, execution, validation and human decision-making.

The solution in four phases

The board and ticket connect planning, execution, validation and human decision-making in one traceable lifecycle.

From plan to executable ticket

A plan is divided into executable phases and subphases. The MCP ticket flow links each part to:

  • clear scope and acceptance criteria;
  • sprint, team and repository;
  • priority, weight and dependencies;
  • risk and required quality checks;
  • evidence requirements and permitted agent actions;
  • review and closure policy.

Board context, available runners and permissions then determine which ticket is actually executable. An agent therefore receives neither an unrestricted backlog nor unrestricted access.

Claim, analyse and execute

A runner can proceed only when the ticket, project context, permissions and configuration allow it. Execution includes:

  • selecting a suitable runner for an allowed ticket;
  • claiming, idempotency and locking to bound simultaneous execution;
  • analysing relevant code, context, risks and dependencies before implementation;
  • making changes in a bounded workspace with mandatory build, test and other checks.

The results of those checks provide evidence for the ticket and linked pull request.

Quality evidence and board synchronisation

The pull request brings together:

  • the change and relevant commits;
  • test results;
  • functional checks;
  • remaining risks;
  • a reference to the original acceptance criteria.

After board synchronisation, a runner can take another permitted ticket while review of previous work remains active separately. Execution and review remain connected but retain their own status.

Human review and targeted rework

A reviewer can:

  • approve;
  • request targeted changes;
  • reject;
  • block.

Feedback returns to the same ticket and starts bounded rework. Merging, deployment, release and closure happen only when the configured policy permits each action explicitly.

Platform architecture

The platform brings the work queue, project context, quality evidence and execution together without collapsing those responsibilities into one unrestricted agent.

Board

The Board stores tickets, priorities, dependencies, runs, evidence, pull requests and review decisions. Ticket and policy logic, PostgreSQL, scheduling and locking support the controlled lifecycle.

Wiki

A connected Wiki provides bounded architecture, domain and project context. An agent can therefore retrieve relevant information without loading all documentation indiscriminately into a single prompt.

Test Plan

The Test Plan connects acceptance criteria, scenarios, quality gates and results. Board, Wiki and Test Plan share the same project and access context.

Runners, MCP and observability

An MCP layer and Git integration connect the platform to local or hosted runners that operate close to an authorised repository in an isolated workspace. Observability keeps runs, errors and decisions traceable.

The MCP layer prevents the workflow from depending on one specific coding agent. Which runners are actually supported remains subject to verified implementation and project configuration.

Hosted and dedicated models

The product vision supports a managed option for smaller organisations and a separated dedicated or self-hosted option for environments with their own identity, Git, CI/CD, data and infrastructure boundaries.

These are delivery models in development, not a claim of general availability. The public product website does not announce a general release date.

Our contribution and qualitative result

Together with Infium, we at 5A Technologies shaped the agentic product and workflow architecture, the MCP-driven ticket model, lifecycle management, prioritisation and agent selection, the path from analysis to implementation and QA, pull-request and board synchronisation, human review and rework gates and the broader vision for Board, Wiki and Test Plan.

Agentic Board brings planning, bounded agent execution, quality evidence and human decision-making into one controlled flow. Agents receive a bounded assignment rather than just a prompt, while teams retain control over changes entering their software.

Deliberate boundaries

  • Agentic Board is not presented as a generally available product.
  • No savings, volumes, success rates or autonomous-success claims are published.
  • Coding agents receive no unrestricted repository or infrastructure access.
  • Automated merging, deployment, release or closure always depends on policy.
  • Internal tools, prompts, tokens, repositories, customer data and security configuration remain outside the public content.

What this project demonstrates

This project shows how 5A Technologies:

  • translates functional and technical plans into bounded, executable tickets;
  • embeds permissions, claiming, idempotency and locking in agent execution;
  • connects implementation, quality checks, evidence, pull requests and board status traceably;
  • keeps agent execution and human review connected but separately controllable;
  • can support several suitable runners through MCP without treating one agent type as the fixed default;
  • brings Board, Wiki and Test Plan together within the same project and access context.

Would you like to discuss a similar solution?

Tell us where your process slows down today or where AI and automation should work together more effectively. We will explore which controlled approach fits.

Discuss your process