Agentic AI Architecture: Enterprise Guide From Our Stack

Introduction

Agentic AI architecture is the set of layers that lets a language model do work instead of only answering: it decides what the model knows, which tools it may call, who coordinates several agents and who has the last word. This enterprise guide is for engineering leads and CTOs in organizations that are past the demo stage of agentic AI and want to see how a working agentic layer is put together.

We describe ours. We built it from two of our own products, Compass and Lantern, plus the CMS and the sales pipeline behind our website, and a repository of versioned skills that works as the toolkit of every agent. Each section takes one layer of the usual reference model and shows what these tools do with it in code.

One thread runs through all of it: human in the loop (HITL). In our agentic AI systems the agents read freely, propose often and change shared data only after a person has seen the change. For every layer we show where that person sits, screen by screen.

What Agentic AI Architecture Means in Practice

Most definitions of agentic AI, a branch of artificial intelligence, stop at "a model that can use tools". That is true, but a team that ships agents needs more: a source of context, a list of actions with limits, a way to split work and rules that hold when the model is wrong. Those are architecture questions, not prompt questions.

What Is an Agent vs GPT?

A GPT-style model is a text predictor. It is trained on large amounts of text, tuned with methods such as reinforcement learning from human feedback, and given a prompt it returns a reply. On its own it remembers nothing between calls and changes nothing outside the conversation.

An agent executes tasks by wrapping such a model in a loop. The loop gives the model tools, runs the tool calls it asks for, feeds the results back and repeats until the task is done or a limit stops it.

The model supplies the reasoning power, and the architecture around it decides what the agent needs to see, what it may touch and when it has to stop and ask.

That difference is why we never judge agentic systems by the model alone. In Compass the same chat model can read Jira tasks, search project documents and grep the connected code, but it cannot post a comment to Jira by itself. The write goes through a form that a person applies.

The Five Core Components of an Agentic Architecture

Ask "what are the 5 components of AI" in this context and the useful answer is five layers. We use this split because it matches how our code is organised:

1. Context layer: what the agent knows before it acts (project maps, saved facts, retrieved documents, conversation history).
2. Action layer: the tools and APIs the agent can call, and which of them write.
3. Orchestration layer: planning, task decomposition and the hand-offs between multiple agents.
4. Governance layer: guardrails, permissions, credentials and roles.
5. Data layer: the databases and stores the other four read from and write to.

Human in the loop is not a sixth layer in our design. It is a property of each of the five: a person saves facts in the context layer, applies writes in the action layer, approves plans in the orchestration layer and merges code at the end.

Types of Agent Architectures

The different types of agent architectures differ mostly in how many intelligent agents work and how much they may do alone:

• Single agent: one model in one loop with a set of tools. The project chat in Compass is this type.
• Multiple agents with an orchestrator: one agent scopes the work and hands it to others, a pattern covered in a widely cited guide to building effective agents. Delegation in Lantern is this type, with an orchestrator, a delegate that writes the change and a reviewer that judges it.
• Vertical agents: models built for one job in one domain, such as the reply drafts for inbound leads in our sales pipeline, or the Analytics Agent in our CMS dashboard.
• Autonomous agents: agents that act with no person in the path.

Most agentic AI systems in production mix these types, and our agentic architecture does too. Some of our agents run unattended, a delegate writing code in its own git worktree for example. What they produce, though, lands where a person reviews it before it counts: a pull request, a draft or a form.

How We Built Our Agentic Layer: Compass, Lantern and Our Tools

Our agentic layer is not one agentic framework or one platform. It is four pieces our team built, each with its own job, plus a shared set of skills that the agents in all of them work by.

Compass: A Project Agent That Proposes

Compass is our project app (it was called PM Helper before the rename). Each project has a chat agent with tools over the project's Jira tasks, its documents, meeting notes imported from Fireflies and the code of connected Bitbucket, GitHub or GitLab repositories. Its Modules page groups the project's tasks into product modules, with an agent that extracts and refines them in a chat.

The rule that shapes Compass is short: the agent proposes, a person applies. A comment, an assignee, a label, a status change, a new task or a release reaches Jira only when someone edits and applies the form the agent drew.

Lantern: Human in the Loop for Coding Agents

Lantern is our desktop app for working with coding agents, and it has been open source on GitHub under the MIT license since 6 November 2026. It watches Claude Code and Codex sessions and shows a live dashboard of each one, maps a project into a .lantern folder, helps plan changes and opens pull requests and local changes for review.

Lantern also ships sixteen skills that it installs into each project it opens: building and refreshing the map, planning, delegating to background agents, reviewing, and reading or updating Jira, Bitbucket and GitHub. We build Compass with Lantern, so the Compass repository carries its own .lantern map, a record for each pull request and approved plans.

Our CMS and Sales Pipeline as Agent Tools

Our website, its CMS and our sales pipeline live in one repository. The CMS dashboard has an AI Editor whose orchestrator model generates articles through tool calls, an Analytics Agent whose tools include Clarity overview and page data, and a social media calendar. Agents outside the dashboard reach the content through small REST APIs, and the blog API lists, searches and exports posts as markdown and imports or updates them.

The sales pipeline finds and classifies leads, our future customers, and writes personalised outbound copy. For inbound leads it researches the person and drafts a reply in the salesperson's own mailbox. This is workflow automation with a person at the end of it: two writes face the outside world, and both stop at a draft. A blog post is imported as a draft, and a reply lands in the Drafts folder.

Skills We Keep and Version in a Repository

The last piece is not an app. Our agents work by skills: instruction files, some with scripts, that encode our conventions, such as how to write a commit message, how to review a change or how to debug. We keep them in one company skills repository, a plain git repo where changes land through pull requests and releases are git tags.

A command links the skills into a project's .claude/skills folder as symlinks into the checkout, so moving the checkout to a new tag updates every linked skill at once. Skills are grouped by who needs them: a baseline every project gets (core principles, tech stack, developer process and security) and one platform role per project, such as Next.js, React Native or the NestJS backend.

Lantern adds a Skills window where a person attaches extra skills to each role (delegate, orchestrator or reviewer), globally or for one project.

The Context Layer: What Our Agents Know Before They Act

The context layer decides most of the quality of agentic systems. In complex environments such as an enterprise project the context is spread over Jira, documents, meetings and code, and a model that sees the wrong file or misses one decision will act confidently on a false picture. So we treat context as data to curate, not as text to paste.

The Lantern README puts it in one line: "Your project, your codebase, is the whole context for your AI."

The Lantern Map as a Semantic Layer for Code

The Lantern map is a .lantern folder of plain files with one record per source file: its architectural role from a fixed vocabulary, a one-line purpose, a content hash and its relations to other files. On top of the records sit features, outside systems, product areas, platforms and project-wide sections such as roles and permissions, entity state machines and the database schema.

For an agent this works as a semantic layer. Instead of reading thousands of lines to learn what a file is for, it reads the purpose and the relations, a light relative of knowledge graphs built for code. The Compass map, for example, names twelve features and seventeen outside systems, from Jira to the vector store.

The map stays true because after the first full run every pull request re-maps only the files it touched, and a person decides when to run Refresh map.

The Compass Project Brain: Knowledge a Person Saves

Compass keeps durable project knowledge in a project brain: what a term means in this business, a convention the team follows, a decision that stands, who owns what. The agent cannot write there on its own. When such a fact comes up in a conversation, it calls propose_memories, and the fact appears as a form the user can edit and save with one click.

Before proposing, the agent must search the brain, because the brain holds facts from conversations it cannot see. If a proposed fact resembles one already saved, the form still appears but carries a warning that names the similar fact, and the person decides.

Each thread runs the brain in full, read-only or off mode, and only full mode allows writes.

Retrieval, History and Attached Documents

The rest of the Compass context is retrieved on every turn. Document search fuses four retrieval legs (semantic, keyword, heading and title) into one ranked list, and documents attached to the thread rank higher. The agent is also told which documents are attached, with their version, and to read them instead of asking the user to paste text.

That instruction exists because the agent once claimed no transcript was attached when one was. History has a budget too: the agent gets a conversation history capped at 200,000 tokens, because the history is re-sent on every turn.

What Agentic Data Means

Agentic data is the data agents read and write as part of their work, as opposed to data that only feeds a report. In our layer it includes the map records, the facts in the brain, the pull request records and the proposal forms themselves. What makes it agentic is that each item carries metadata about where it came from and who approved it.

Lantern's plan files show this well: every approved section is stored with the name of the person who approved it, the date and a short hash. In Compass, the list of changes made by the Modules agent is stored with the message as metadata and shown in a collapsed Changes list, so anyone can check what the agent moved, created or deleted.

This is also our view on agentic analytics. Before you measure what agents do, record it in a form a person can read back, and the data layer underneath (Convex databases in Compass and in the CMS, plain files in the Lantern map) becomes an audit trail as well as storage infrastructure.

The Action Layer: Agents Read Freely, People Approve the Writes

The action layer is the list of tools and the rule for each one, and it is where you see how agentic systems work in practice. Our main rule fits in one sentence: reading is cheap and safe, so agents read freely, and writing to shared systems goes through a person.

Agent Capabilities: Tools and APIs Our Agents Call

The chat agent in Compass has more than thirty tools. Most of them only read:

• search_tasks
• get_task
• gettask__comments
• searchproject__docs
• readproject__document
• getdirectory__tree
• grep_files
• read_file

The tools that would change Jira all start with propose, so nothing is written until a person applies the form:

• proposetask__update
• proposetask__comment
• proposetask__assignee
• proposetask__labels
• proposetaskstatus
• propose_tasks
• propose_release
• proposetask__attachments

A few tools write inside Compass itself, and each carries its own limit. edit_document must pass the version it read, and the edit is refused if anyone changed the document since.

The model context protocol (MCP) is a common technology for exposing tools like these to a model. Compass defines its tools in its own code, and the Lantern skills reach Jira, Bitbucket and GitHub with the account a person added in the app, so no token is typed into a chat. Whatever the wiring, the question per tool stays the same: does it read or write, and who approves the write?

Approval Forms Rendered With MDMA

A proposal in Compass is not a line of text asking "shall I do it?". It is an interactive form written in MDMA, our open source Markdown format for interactive documents written by an LLM, and the person edits it before applying. A comment arrives as editable text, an assignee comes resolved by name or with a list of candidates when the name is ambiguous, and a release lists the tasks to add.

Apply is the only path to Jira. An empty comment is refused before any call, and the signed-in user is chosen through an explicit flag, never from the wording of a name.

The forms are built by the server, not by the model. When a model once wrote its own task form with an unknown submit action, Submit did nothing, silently. Since then hand-written MDMA blocks in the assistant's text are always dropped, and only forms built by the tools reach the screen.

When the Agent Says a Form Exists and It Does Not

Human in the loop only works if the person sees the real thing. In one production thread the agent kept replying that the form was in the chat and the user should click Apply, while no form had been built. Only after several complaints did it call the tool.

The fix moved the check out of the prompt. The agent now starts its final reply with a machine tag, answer or proposal, and the app compares the tag with the forms the tools built. A reply that claims a proposal without a form is sent back once with a required tool call, and then replaced with an honest line.

On a replay of that production thread, the model passed 44 of 96 runs before the change and 92 of 96 after it. Our AI experimentation runs on evals, including replays of real threads, not on a feeling that the agent behaves better.

The Orchestration Layer: Plans, Delegates and Reviewers

Orchestration is where complex tasks and complex workflows get split and handed out. For code, our agentic workflow runs through Lantern here, and every hand-off has a person at one end of it.

A Planning Workflow Approved Section by Section

For a larger change we first write a plan with the lantern-plan skill. The plan is a file under .lantern/plans, tied to the map: a goal, a scope, an impact section computed from the map rather than guessed, ordered stages of items with an acceptance check each, the open questions of each stage and the risks.

The user approves it one section at a time, and the rule in the skill is strict: only the user approves, never on a silence and never for a section they did not see. Editing an approved section makes it stale, so it has to be shown and approved again. Open questions stay with the stage they block and are asked again before that stage is delegated.

The Compass plan for Jira comments, assignment and images shows the result. Its scope says the agent may comment on and assign tasks "after approval", and the file records Marcin's approval of each section and then of the whole plan, all on 4 November 2026.

One Goal per Delegate, Three Agents With One Job Each

An approved plan goes to lantern-delegate, which turns its items into tasks for background agents. Each delegate gets one goal, works in its own git worktree and cannot ask a question once it starts, so everything it needs is settled before dispatch. A request gets three delegates at most, and our task decomposition rule is simple: if a goal needs an "and", it is two tasks.

The skill describes the split as three agents, one job each. The orchestrator scopes the task, the delegate writes it and a reviewer that wrote none of the code judges it. A mid-sized model is the default for delegates, and complex workloads go to a stronger one only after the user answers that one question for that task.

A person also decides how work is delivered, once per project: a pull request, a pushed branch or local commits only. The orchestrator never merges. In the words of the skill, merging is "a human's call, on the host".

Reviewing What Agents Changed

A pull request opened by a delegate ends with a record in .lantern/prs: a reason for each changed file, the review order and a plain-words flow of the change. Lantern shows it next to the file list, the diffs and the graph with the touched files marked, so the review opens already explained.

The orchestrator reads the record before handing it over, and a reason that only restates the file name goes back to the delegate. For changes with no pull request yet, local review gives the same view of uncommitted work or a branch.

Monitoring Sessions and Approvals

Monitoring is a human-in-the-loop problem too: an agent that waits for approval in a hidden window does nothing. The Lantern dashboard lists every session with its project, state and last reply, and sends a menu bar and native notification when a session finishes, needs approval or waits for input.

Compass covers the cost side. Each chat thread shows its cost and tokens, and the Modules agents call their models directly with prompt caching and log their cost and cache tokens per run.

The Governance Layer: Guardrails That Keep People in Charge

Governance is where an agentic architecture proves itself, because a prompt is a request and code is a rule. We put the rules that matter into code and tests.

Guardrails in Code, Not Only in Prompts

The clearest case came from the Modules page in Compass. Asked to make modules more specific, the refinement agent deleted all nine modules, created none and asked which platform the project was. The prompt had not stopped it.

The rebuilt page stages deletions and applies them only when a code-level finalize passes. A second deletion in one run is blocked unless the user's message asked to delete or merge, and the same goes for any module a person approved or created: the agent gets a refusal telling it to change the module instead. A replay of the incident now ends with every module still in place.

That pattern, a person's decision outranks the agent's, is the core of our governance. A fact a person saved, a module a person approved, a plan section a person signed: the agent may propose a change to each, never override it.

This also answers what the OWASP list of LLM risks calls excessive agency: an agent given more power than its task needs. Regulators point the same way, and Article 14 of the EU AI Act requires high-risk AI systems to be designed so that people can oversee them.

Permissions, Credentials and Roles

Lantern keeps one list of commands an unattended agent may run and a deny list it must never run, and its maintainers' rule is to never widen a rule to make a run pass. The Bitbucket and GitHub skills never merge, approve, delete or force-push, and the Jira skill never deletes or bulk-edits.

Compass stores Jira, Bitbucket and Fireflies credentials encrypted with AES-GCM. Project access is checked in code for each role (admin, project manager and teammate).

The CMS and the sales pipeline apply the same idea in their own way. The mailbox code only ever writes drafts and never sends, setup of AI reply drafts is admin-only, and other users see the drafts and can ask for a new one. The social calendar API runs every write as a named user, so permissions and authorship match a click in the dashboard, and its posts move through an approval workflow from draft to pending approval, approved and published. Blog imports are drafts by default, invisible on the live site until a person publishes them.

Building Enterprise Ready Agentic Systems

What would we tell another enterprise team building such a layer? The list is short:

• Split tools into reads and proposals, and make Apply the only path to a write.
• Keep context in files and records a person can read and correct, not only in embeddings.
• Store who approved what next to the thing that was approved.
• Put limits in code with tests, and replay real incidents as tests.
• Measure agents with evals: Compass runs promptfoo suites for tool routing, the proposal tools and task assignment.
• Let people choose the expensive things: the model for a hard task, how work is delivered, when a map is refreshed.

None of this needs a large platform team. It needs a clear answer, per tool and per layer, to the question of who decides.

What is your AI actually costing you per task?

We instrument AI agents to price every LLM call, then cut the bill with context trimming, role-based model routing, prompt caching and fallbacks, measured before and after. Send us a short description of your agent and its monthly volume.

Matt Sadowski

CEO

Business email*

Full name

By sending this form I accept the terms of Privacy Policy *

Success!

Your message has been sent.

Our sales representative will contact you shortly.

Ok

Conclusion

Agentic AI architecture is less about the intelligence of the model and more about the layer around it. Ours is built from Compass, Lantern, our CMS, our sales pipeline and a repository of versioned skills, and human in the loop runs through every layer of it.

• Context is curated data: a map of the code, a brain of saved facts and retrieval with a budget.
• Actions split into reads and proposals, and a person applies every write to Jira.
• Orchestration runs on plans a person approves section by section and on delegates that never merge.
• Governance puts a person's decision above the agent's, in code and in tests.
• Writes that reach the outside world, such as replies to leads and blog posts, stop at a draft.

If you want to try the coding half of this, start with Lantern: map one project, plan one change and review the first pull request a delegate opens for it.