Software engineering agents
PlannedReview, test and change-management assistance inside existing engineering workflows.
Andiamo Enterprise · Software engineering
A review is a judgement, and it stays one.
Planned work: a change under review is read together with the code around it, a test or a note is offered, and the engineer reviewing it decides what to keep.
How the work would run
The shape of the work, step by step.
Who the work belongs toEngineers reviewing each other's changes, and the people who look after the checks those reviews lean on.
Andiamo Enterprise is a planned product line. Steps marked for approval are designed to wait for a person, and the status beside each step is taken from the registry entries it would lean on.
Review
PlannedA change under review is read with the code around it
Andiamo Enterprise is planned, so this describes a design rather than a product you can install. A change waiting for review is read together with the code it touches, the tests that cover it and the conventions the team already applies. Gathering that into one packet is context assembly, a Core part in development.
Suggestion
PlannedA test or a review note is offered, not applied
What comes out is a suggestion sitting where the team already reviews: a case that looks unhandled, a test worth adding, a question about a boundary. It is written to be argued with, and it carries the reasoning that produced it so an engineer can dismiss it quickly when it is wrong.
Human approvalChecks
PlannedA suggestion earns its place by passing the checks the team already runs
A suggested test that does not run is noise. Putting suggestions through the same checks as anything else is how the volume of them stays useful rather than becoming the problem. Evaluation suites and graders exist for some agents and are run by hand; scorecards and release gates are still being built.
Merge
PlannedThe engineer decides, and the decision is recorded
Taking a change into the codebase stays with the person who will own it afterwards. Where a step waits for approval, the decision is recorded with who made it and when: approvals and decision records are a Core part in development, not yet switched on in a live product.
Human approvalSignal
PlannedEdits and rejections are the signal worth keeping
Which suggestions were taken, which were rewritten and which were ignored says more about the work than a score does. Feedback capture is a Core part in development, recorded in a few places today rather than as one stream. Routing each step to a model or to plain code is the one piece in pilot, running in our own engineering operations.
Where each step stands
Each step, and the parts it would need.
Review
PlannedSoftware engineering agentsPlannedContext assemblyIn developmentSuggestion
PlannedSoftware engineering agentsPlannedApproval-gated agentsHuman approvalPlannedChecks
PlannedSoftware engineering agentsPlannedEvaluationIn developmentMerge
PlannedApproval-gated agentsHuman approvalPlannedApprovals and decision recordsHuman approvalIn developmentSignal
PlannedSoftware engineering agentsPlannedFeedback captureIn developmentModel routingIn pilot
What this leans on
Planned above, partly built below.
The agents for this domain are planned: designed, and not built. Underneath them sit the Lamiak Core parts they would rest on. Most of those are in development, exercised in testing; model routing is the one in pilot, running in our own engineering operations. The full list is on the product page.
The agents this domain would need
Approval-gated agents
PlannedAgents that propose actions inside your systems, with a person approving and a record of each decision.
Human approval
Underneath, in Lamiak Core
Approvals and decision records
In developmentSelected actions wait for an owner or admin to approve or reject them, and each decision is recorded with who decided and when; not yet switched on in a live product.
Human approval
Context assembly
In developmentGather the records and permissions an agent needs for a task into one packet before it acts; built for selected workflows, and packets are not yet saved for review.
Model routing
In pilotRoute each step to a model or to plain code based on task type, cost and data sensitivity. Running in our own engineering operations.
Feedback capture
In developmentRecord how people respond to AI suggestions, including edits and rejections, and whether they found them useful; captured in a few places today, not yet as one feedback stream.
Before it ships
What would have to be true first.
- A decision record a reviewer can read backIn development
- An engineer asked to trust a suggestion will want to see what the agent was given and what a person decided afterwards. Decision records are partly built and exercised in testing, and no product runs on them yet.
- Evaluation that decides what is worth showing at allPlanned
- Suggestions that are usually wrong cost more attention than they save. A suite that measures which ones survive review, and a gate a candidate has to pass before it is given authority, are still being built.
- The code and its history assembled as one packetIn development
- Reviewing against the code around a change means gathering that context reliably and keeping it for inspection. The first half is built for selected workflows; the second is not.
- A place inside the review workflow a team already runsPlanned
- Suggestions that arrive somewhere else become another inbox. Reaching into an existing engineering workflow is what this line is for, and the line is planned: no enterprise edition exists in any repository.