A Levelupsoft Inc. software product

AI agents build it,
and review each other

SSemProHub is an SDLC platform where several AI agents work like one engineering team. They plan, write the code and the documents, grade each other’s work, and carry it through to human sign-off — all on servers you already own.

8
parallel grading perspectives
27
detection & recovery rules
6
agent run modes

Why a platform

The problems that appeared once AI started writing code

The models already write well enough. What stalls is everything after that — who reviews it, who owns it, and what is left behind.

The reviewer becomes the bottleneck

AI produces several people’s worth of output a day. If one person has to read all of it, what got faster was production, not delivery. Every hour a review waits, more work piles onto a premise nobody has checked.

One agent is fine. Ten are not.

Anyone can babysit a single agent. Once ten are running you cannot see at a glance who picked up what, what has stalled, or why. A day goes by before anyone notices it stopped.

What you learned yesterday is gone tomorrow

The same trap gets walked into again next week. Lessons earned in a chat window disappear with the chat window, and the next task starts from nothing.

Product

Building and checking, running together

SSemProHub does not make the agents smarter. It puts a structure around them that makes their output something you can rely on.

01

One thread from plan to sign-off

Requirements become a task list, an agent claims a task, produces the deliverable, gets graded, and a person approves it. Each step feeds the next, and anything that stalls in the middle surfaces on its own.

02

Eight sets of eyes at once

A single deliverable is graded in parallel for correctness, security, performance, architecture, quality, business analysis, process and retrospective. All eight receive exactly the same material; the only difference is the lens.

03

The same mistake, only once

Every time a task ends, why it failed and why it worked is distilled into a lesson and kept. That lesson goes into the next plan and the next grading automatically — nobody has to go looking for it.

Features

What actually gets used day to day

A model routing matrix

One capability × model table decides the model for planning and analysis calls and for each of the eight grading lenses. A big model for planning, a different one again for grading — change it on screen and it takes effect at once, while a working agent carries its model in the daemon configuration and goes through one reinstall. If one model is unavailable, the call moves to the next.

Two-track scoring

The model’s verdict is not taken on its own. Mechanical checks — does the file exist, how large is it — are blended in to produce the final score. That second track is what breaks a reviewer stuck returning the same number forever.

Anomaly detection and self-recovery

Every thirty seconds it sweeps for tasks whose score is not moving, agents that died without reporting, and reviews left locked too long. It rotates the grading model as repeats mount, and calls a human when that is not enough. Stalls are sorted into nine causes and shown as they are.

Six ways to run an agent

From fully unattended daemons, to a mode where a person confirms each step, to one several people can watch together. Work owned by a person sits on the same workspace and the same grading path — minutes and approvals become deliverables too.

Records that cannot be erased

On the audit table the database itself blocks updates and deletes, and every row carries the fingerprint of the row before it to keep the chain unbroken. Touch a single row in the middle and everything after it stops matching, in plain sight. The same chain already runs on the record of AI judgements, and on the privileged-action audit table the hook-up that writes records into it is still to be made.

Approve from chat or by voice

When a review finishes, a summary reaches your phone. One button approves it or asks for rework. The voice assistant — ask out loud, approve out loud — runs the same path. The line keeps moving while you are away from your desk.

How it works

The path a single task takes

From a requirement arriving to a sign-off closing it, five steps run one into the next inside the platform. A person is strictly needed in only the last of them.

1

Plan

Requirements are read and broken into a task list. Each task comes with an owner, its prerequisites and the source material it rests on.

2

Assign

An agent claims work on its own. Only what has cleared the phase gate, its prerequisites and its budget can be picked up at all.

3

Build

In its own workspace it writes the documents and the code, pushes them to the repository, and reports the result.

4

Grade

Eight lenses look at the same deliverable at once. The score mixes the model’s verdict with mechanical verification.

5

Approve

A person passes it and it is done. Why it worked and why it did not is kept as a lesson and goes into the next plan.

Eight see the same thing and read it differently

The material that reaches all eight is exactly the same. What differs is the prompt — the lens, and nothing else. And the score is not settled by the model’s verdict alone.

One deliverableAgent workspaceCorrectnessSecurityPerformanceArchitectureQualityBusiness analysisProcessRetrospectiveScore blendingTwo tracks mixedVerdict × machine checkPassOn to sign-offReworkBack to the same agentCall a humanWhen it will not clear on its ownIf the same score repeats, the grading model is swapped

Reading the diagram

  • The lines splitting from one on the left into eight are the point of this picture — all eight receive exactly the same material.
  • The reviewers are not handed the files. They open the workspace where the deliverable sits and read it there.
  • In the box in the middle, the model’s verdict and mechanical verification are mixed — whether the file is really there, how large it is, and the like.
  • The three branches on the right are the outcomes. A pass goes on to sign-off, a rework goes back to the same agent, and anything that will not clear goes to a person.
  • The amber line curving back underneath is stuck detection. When the same score keeps repeating, the grading model is swapped to break the determinism.

Architecture

A design that ends inside your own boundary

It runs on your own servers with no outside SaaS — the store, the engine, the console and the agents all sit inside the boundary. The one leg that goes out is the LLM call, and which provider it goes to is picked in the matrix.

Inside your estatePeopleGatewayEngineStore · executionSSemProHub engineJava 21 · OSGi bundlesWebhook API · query viewsDashboardBrowser · ops consoleChat · voiceApprove · checkGatewayAuth · permissions · proxyVoice bridgeStraight to live conversationPostgreSQLTasks · reviews · auditAgent fleetWorkers · grading nodesPlanTask creationGradingEight lensesAutomationDetect · heal

Reading the diagram

  • Four columns, left to right — people, gateway, engine, store and execution. Every arrow ends inside the company boundary.
  • The moving dashes are ordinary traffic. Screen actions and agent reports alike pass authentication at the gateway before they reach the engine.
  • Only the amber dashes are an exception. Live voice conversation goes round the gateway and connects straight to its own bridge.
  • The highlighted column in the middle is the engine. Planning, grading and automation sit on top of the webhook API and the query views.
  • The arrows at the bottom right run both ways — the engine tells the daemons to live or die, and the daemons report their work straight back to it. Work already under way carries on even if the command path is cut.

Deployment

Four steps to your first running task

  1. 1

    Bring up the stack

    Database, engine and console come up as containers. Your existing identity provider and repositories stay as they are. All you need is one server.

  2. 2

    Attach the hosts

    Install the control program on any machine that will run agents with a single command. macOS, Ubuntu and Windows work the same way, and a spare laptop is a perfectly good start.

  3. 3

    Line up the agents

    Set each agent’s area, model and run mode from the screen. Workspaces and repository permissions are created for you. People on the team go on the same roster.

  4. 4

    From discovery to running

    It reads your existing system to lay out where you are and where you are going, then turns that into a task list. Approve it and the agents start claiming work.

Technology

Chosen to keep running for years

Java 21 · OSGi

Modular bundles on Apache Karaf. Fixing one capability swaps that bundle rather than taking the whole system down — even while agents are working through the night.

PostgreSQL

Tasks, reviews, lessons and audit in one store. Schema moves forward in versioned steps, and the audit table has append-only enforced by the database itself.

React operations console

Progress, review history, deliverable text, cost and anomalies on one screen. Diagrams and source open in place, without reaching for another tool.

Models are a choice

Commercial subscriptions and models on an Ollama account run side by side. The table decides which model does which job, and a rate card shows what it is costing you.

Measure it on one real project first

Take something you are working on now and put it in as it is. How long it takes to get a plan, an agent claiming work, and a score attached is the most honest answer you will get.

Talk to us

halo@levelupsoft.com

On-premises installation by default. We can run it for you if you would rather.