IT operations agents
PlannedTicket triage, access requests and runbook execution with approvals.
Human approval
Andiamo Enterprise · IT operations
A ticket is a decision somebody still has to make.
Planned work: a request is read against the systems it touches, a change is written out in full, and the person who owns that system decides.
How the work would run
The shape of the work, step by step.
Who the work belongs toThe team that runs internal systems and answers the requests that land in their queue, alongside the owners who have to sign off on a change.
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.
Ticket
PlannedA request arrives where the team already works
Andiamo Enterprise is planned, so this is the shape of the work rather than software you can run. A request for access, a fault report or a routine change lands in the queue the team already uses. The work starts by reading it: what is being asked for, which system it touches, and who owns that system. Nothing is acted on at this point.
Triage
PlannedThe records and permissions the request touches are gathered first
Before anything is proposed, the records, the ownership and the permissions the task would need are gathered into one packet. Context assembly is a Lamiak Core part, built for selected workflows and in development; the packets are not yet kept for anyone to read back, which is one of the reasons this line is not offered.
Change
PlannedA change is written out before anything is touched
The agent describes what it would do, in which system and why, in the terms the owner of that system would use to judge it. The proposal is the unit of work; the action waits behind it. Where policy says so, a person approves before anything changes.
Human approvalDecision
PlannedThe owner approves, edits or rejects, and the record says who
A person decides on the exact change, and that decision is recorded with who made it and when. Approvals and decision records are a Core part in development, exercised in testing and not yet switched on in a live product, so the record this step depends on is not something you can inspect today.
Human approvalFeedback
PlannedWhat the owner changed matters more than what the agent wrote
An edited or rejected proposal says where the work was misread, and that is the part worth keeping. Recording how people respond to suggestions, including their edits, is a Core part in development and captured in a few places today rather than as one stream. Routing each step to a model or to plain code by task, cost and data sensitivity is the one piece in pilot: it runs in our own engineering operations.
Where each step stands
Each step, and the parts it would need.
Ticket
PlannedIT operations agentsHuman approvalPlannedContext assemblyIn developmentTriage
PlannedIT operations agentsHuman approvalPlannedContext assemblyIn developmentChange
PlannedIT operations agentsHuman approvalPlannedApproval-gated agentsHuman approvalPlannedApprovals and decision recordsHuman approvalIn developmentDecision
PlannedApproval-gated agentsHuman approvalPlannedApprovals and decision recordsHuman approvalIn developmentFeedback
PlannedIT operations agentsHuman approvalPlannedFeedback 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.
- Approvals switched on in a live productIn development
- Decision records exist in Core and are exercised in testing; no product runs on them yet. Until one does, the approval step above is a design and not a control you could audit.
- Context packets kept where a reviewer can read themIn development
- A proposed change can only be judged if the records and permissions behind it can be read back. Assembling the packet is built for selected workflows; keeping it is not built.
- Evaluation before a model holds any authorityPlanned
- Suites and graders exist for some agents and are run by hand. Automatic scorecards, and a gate a candidate has to pass before it is given authority in production, are still being built.
- A way into the systems the requests are aboutPlanned
- Reading a queue and acting inside an identity or device system means connections, scopes and permissions that do not exist in any repository today. The agents for this domain are planned, and that is what the status on them says.