Skip to content
lagstyr.Register interest

The Lagstyr handbook

  1. For the person who decides
  2. What Lagstyr is for you
  3. Reading your console
  4. What needs your attention
  5. Deciding a proposal
  6. After the decision
  7. Operating the work
  8. Agents and their runs
  9. Governing the company
  10. Access, people and language
  11. For the person who administers
  12. Administering your console
  13. Bringing an agent into service
  14. Defining and promoting action classes
  15. Registering AI systems
  16. Emergency access, passwords and sessions
  17. Sources, structure and the operations index
  18. What this installation connects to
  19. For engineering and DevSecOps
  20. Planning an installation
  21. Installing Lagstyr
  22. Securing your installation
  23. Building and commissioning integrations
  24. Commissioning agents and retrieval
  25. Monitoring and routine operations
  26. Upgrading and managing releases
  27. Backups, restoration and recovery
  28. Responding to incidents
  29. Reference
  30. Glossary

Documentation · The Lagstyr handbook

What Lagstyr is for you

You are reading this because your organisation runs some of its work through agents, and you are one of the people who decides what those agents may do. Lagstyr is the record and control layer that sits between their reasoning and your company’s transactions. It holds the mandate that authorises a piece of work, the evidence behind it, the decision a person made, the approval that recorded it, the effect that followed and the obligation it left behind.

Our published guide to AI-native operating architecture puts it this way:

The guide tells an organisation to put a deterministic control layer between AI reasoning and business transactions; lagstyr implements the deterministic authority, approval and audit spine of that layer as company-controlled infrastructure.

Two things follow from that sentence, and they shape everything in this book.

Agents propose; people decide. An agent in Lagstyr can read, draft, extract, flag and, inside a certified boundary, execute. It cannot approve, and it cannot widen its own authority. Every change to authoritative state is a proposal, and a proposal becomes an effect only when a person with the right mandate decides it, or when the class of action has earned the right to run without a case-by-case decision and is reviewed by exception afterwards.

Lagstyr does not replace the systems you already use. Your accounting, payroll, customer and document systems keep the facts they own. Lagstyr records the mandate, decision, approval and verified effect across them, and it says, on every page, which of the two it is showing you.

Autonomy is routed by tier

Delegated work is routed by how much autonomy its class of action has earned, before anybody discusses approval. Lagstyr’s public description of the tiers is the one to hold in mind:

TierOperating contract
T0 — readRead authorised evidence and projections; create no effect.
T1 — draftPrepare work for an independent actor to commit. This is a reference tier; the current runtime has no distinct T1 route.
T2 — act after approvalStop before the effect. A human approves the exact governed proposal, then the kernel applies it.
T3 — act within a certified boundaryExecute a bounded, observable, reversible or compensatable action directly, then apply deterministic sampling and exception review as post-action assurance.

T3 is not a general permission to act. Sensitive, irreversible or high-consequence effects stay at T2, where you decide each one. A class of action moves toward T3 only through its own evidence, limits, review results and automatic demotion triggers, never through a change of appetite.

Most of what you do in your console is T2 work: reading a proposal and deciding it. The rest is T3’s other half: looking at what an agent already did, and saying whether it was right.

What this book is

This book has three parts. The first is for the person who approves proposals, reviews what agents did, raises exceptions and reads the registers; it walks your console by task, in the order the console itself presents them: decide, operate, govern, investigate. The second is for the person who administers the console: who brings an agent into service, defines the classes of action it may take, registers the AI systems the company runs, and holds the emergency keys. In a small installation those are the same person. The third is for engineering and DevSecOps: the people who plan and install the deployment, connect it to other systems, secure it, monitor it, upgrade it and recover it. Start with the part that matches your responsibility; bringing a service up and authorising the work it may perform are separate decisions.

The words on the console’s pages carry precise meanings. The glossary in this book is generated from the same source your console uses, so a term means the same thing in both places.

What this book does not promise

This book describes the console and installation tooling as they are built. Whether a particular connector, identity provider or workflow has been commissioned in your installation is a fact about your installation, not about the product, and your console tells you when it is showing a plan rather than a record. When the console says a figure is a projection, believe it; when it says it holds no authority of its own, that is the design working.

Next chapter
lagstyr.
ContactSecurityPrivacyTerms