Anatomy of an Agent: A Configuration, Not a Program
The ten declared parts every Nagent agent is built from
On Nagent an AI agent is a configuration, not a program. Every agent is the same chassis carrying ten declared parts: triggers, model, memory, skills, trust, autonomy, tools, external tools, budget and surfaces. Each part holds a stored value with a named owner and an audit trail, so an agent can be reviewed, changed and retired without touching code.
Overview
Most agent projects stall on a governance question, not a capability question. The model is competent. What stops the rollout is that nobody can say precisely what the agent is allowed to do, who approved it, what it costs, and what happens when it is wrong. Those answers usually live in code, in a prompt file and in somebody's memory of a meeting.
Nagent moves every one of those answers into stored configuration. Every agent on the control plane is the same chassis carrying ten declared parts, and changing what an agent is means changing settings on those parts. Each setting has a named owner, a stored value and an audit trail. Nothing about an agent is buried in code.
The ten parts
The specimen used throughout this page is a customer state agent built for a retail customer: it reads customer records, scores intent and writes the next best action back to the CRM for a person to approve.
| Part | What it holds | What changes when it changes |
|---|---|---|
| Triggers | Schedules and named events that wake the agent | When it works; nothing about what it may do |
| Model | The reasoning model, set per agent over the platform default | Cost and speed per run, never its permissions |
| Memory | Operator rules and brand voice, plus its own record of what worked and what failed | What it knows before every run |
| Skills | Attached procedures, each with a priority weight | How it approaches repeat work |
| Trust | A score out of 100, rebuilt nightly from five signals | How much autonomy it can hold |
| Autonomy | The level it holds, from locked to fully autonomous | Whether a permitted action runs now or waits |
| Tools | The platform actions it may invoke, enforced by scope | What it can do inside the workspace |
| External tools | Actions in outside systems, granted one key at a time | What it can reach beyond the workspace |
| Budget | Daily and monthly caps in currency, enforced by the runtime | How much it may spend, and what happens on breach |
| Surfaces | The record types it may write: finding, analysis, plan, draft, result | What it leaves for colleagues to pick up |
Triggers. Work starts on a schedule, or the moment an event fires. Triggers decide when the agent activates and nothing else does. An agent with no trigger is not broken; it simply only ever runs by hand. Removing every trigger takes an agent off the clock without changing a single permission it holds.
Model. The language model behind every output, set per agent and overriding the platform default. A small, fast model runs high-volume synthesis; a stronger one runs judgement. Changing the model changes cost and latency immediately and changes nothing about what the agent may do.
Memory. Memory works at two speeds. A creator layer holds the rules and brand voice an operator wrote. A performance layer holds the agent's own observed tendencies, recent successes and recent failures. The agent reads its performance layer before every run and writes back after every verdict, and every run's assembled context is kept, so any belief the agent holds can be traced to the runs that produced it.
Skills. Skills are the habits between the model and the memory: written procedures from a shared catalogue, attached and detached without editing the agent. Each carries a priority weight, so an agent holding several knows which leads when two apply to the same turn. The specimen carries five, with intent signal scoring and cohort analysis weighted above engagement scoring. Attaching a skill is the cheapest extension there is: no new permission, no new spend ceiling, no code.

Trust. A score out of 100, rebuilt every night from five signals: operator overrides, escalations, tool errors, governance violations and negative feedback. Trust is not a sentiment. It is a running record of how often people had to step in, and a score that drifts down pulls the agent's autonomy down with it, without anyone filing a ticket.
Autonomy. The level the agent holds, set alongside a risk level. At the specimen's level, audit only, read-only work fires freely and anything caught by a blocking guardrail or an approval policy waits. Autonomy is the single dial that decides whether a permitted action happens now or waits for a person.
Tools. The actions the agent can invoke inside the platform. Scope is enforced: only ticked tools are sent to the model, on every round of every run. The specimen is sent 19 of the 102 tools available to it, which keeps about 3,200 tokens of tool schema in each round and saves roughly 1,300. A shorter list is a safety control and a cost control at once: a shorter prompt, and fewer wrong choices on offer.
External tools. Actions in systems beyond the platform, granted one action key at a time. Anything not on the list is rejected at the gate rather than attempted and failed. Each action carries a scope, and an unscoped action is reachable by every agent in the workspace.
Budget. Daily and monthly caps in currency, with a live meter and a 14 day trend. The specimen runs on 5 USD a day and 100 USD a month. Caps are enforced by the runtime rather than requested of the model, and the breach behaviour is chosen, not assumed: on breach the agent queues actions for approval instead of stopping, so a busy day delays work rather than losing it.
Surfaces. The record types the agent may write and how each renders on the team board. Surfaces are how an agent leaves something a colleague can pick up, rather than an answer that disappears with the session. An agent with no surfaces declared can reason and act and leaves nothing anyone else can work from.
One chassis, three colleagues
Three agents doing unrelated work run on the same ten parts, the same workbench and the same governance. Almost every row differs, which is what makes the chassis worth having. The values below are one workspace's stored configuration on the day this page was written; they move as each agent's record does.
| Part | Customer state agent | Outbound sales agent | Blog writer |
|---|---|---|---|
| Triggers | Event driven, no schedule | Reply and stage events | A schedule |
| Model | A small, fast model | Platform default | Platform default |
| Memory | On, continuous learning | On, continuous learning | On, continuous learning |
| Skills | Five, scoring and analysis | Outreach composer, reply classifier | Sourced drafting |
| Trust and risk | Medium risk | High risk | Medium risk |
| Autonomy | Audit only | Suggest only, while its record is built | Execute with approval |
| Tools | 19 of 102, scope enforced | Research, CRM writes, send | Knowledge base search |
| External tools | Whitelist enforced | Contact enrichment, email delivery | None |
| Budget | 5 USD a day, 100 USD a month | Not capped | Not capped |
| Surfaces | Finding, analysis, plan, draft, result | Draft, result | Draft |
| Reporting line | None, it is a root agent | Reports to the sales lead agent | Reports to the content lead agent |
| Guardrails | Four, three of them blocking | Approval before any external email | Banned phrases, a source per claim |
Two of these agents share a model and all three share a memory setting. What separates a sales agent from a content agent is a tool list, a trigger, an autonomy level and a set of guardrails: a dozen values in a database. That has a commercial consequence. A new agent is a configuration exercise measured in hours, not an engineering project measured in sprints, and the tenth agent costs far less to stand up than the first because the chassis, the governance and the operating discipline already exist. The agent builder takes a one line description and returns a provisioned agent with skills, tools, triggers and guardrails filled in, which an operator then edits rather than authors.

Empty settings inherit a platform default rather than failing, so an agent with nothing set on a part still runs, on the defaults the workspace chose.
Autonomy is a rank, and rank is earned
Autonomy is not a switch on the agent. It is a level the agent holds, and it can be lost as well as gained. The full framework is published as The Earned Autonomy Ladder; the five levels read like this on an agent's profile.
| Level | Fires without asking | Queues for approval | What the person does |
|---|---|---|---|
| Locked | Nothing | All work, including read-only analysis | Acts on every output. Used for a first week in production or an agent under review |
| Suggest only | Read-only work: research, scoring, synthesis | Everything with a side effect. Drafts are visible and never sent on their own | Reads the drafts and sends what is good |
| Execute with approval | Read-only work, and anything already approved in pattern | Each side-effecting action, one at a time, before it runs | Signs off; the approval queue carries a deadline in hours |
| Audit only | The full remit, logged for review | Only actions caught by a blocking guardrail or an approval policy | Reviews after the fact and overrides where needed. Every override feeds trust |
| Fully autonomous | Everything the whitelist permits | Nothing by default. Guardrails and budget caps remain the brakes | Watches the fleet rather than the agent. Reserved for low-risk agents with a long clean record |
Three settings decide whether an action happens
An action that reaches the outside world has to clear three independent gates, and confusing them is the most common design error in agent deployments.
Whitelisting decides whether the action exists for this agent at all. An action that is not granted is rejected at the gate.
Autonomy decides whether a whitelisted action runs now or waits. Read-only work fires from suggest only upward; side-effecting work queues until the agent holds audit only.
Triggers decide when the agent wakes up in the first place. Whitelisting a send action never causes an email to be sent, because nothing has told the agent to run.
Each whitelisted action also carries a scope. An unscoped action is reachable by every agent in the workspace, which is what a workflow's blast radius panel reports at design time. Narrowing an action to named agents stops any other agent reaching it, whatever its own tool list claims.
Extension happens in four places
An agent gains new ability by attaching something to a declared part. Each attachment is reversible, versioned and visible on the profile the moment it is saved.
- Attach a procedure. Skills come from the catalogue with a priority weight and are attached without touching the agent.
- Grant an action. Tools are granted by action key and enforced by scope. Fewer tools mean a shorter prompt and fewer wrong choices.
- Declare an output type. Surfaces name the records an agent may write and how each renders on the team board.
- Put it on the line. A reporting line is a single agent key. Hand-off targets are derived from it rather than stored: parent, children, root, and sideways to a function specialist.
Before an agent can do useful work, its profile shows a short checklist: give it a voice, turn it on, give it a tool, put it on the reporting line, and decide when it runs. Off the line it works alone; with no schedule, event or registry trigger it only ever runs by hand.
Governance is per agent, not per fleet
Fleet-level policy is too coarse to be useful and too blunt to be safe. Each agent carries its own guardrails, approval and execution policies and spending caps, drawn from a shared template library so the rules stay consistent without being uniform.
Guardrails have a severity, a category and an enforcement action. A blocking guardrail stops the action; an advisory one warns the agent and the work still runs. The specimen carries four:
- Blocking, cost cap: pause the agent once daily model spend reaches 50 USD.
- Blocking, tool restriction: no customer-facing or execution tools. The agent may read, score and write records, never send or act on a customer's behalf.
- Blocking, approval required: next best action suggestions queue for a person or a downstream approval before any customer sees them.
- Advisory, content restriction: personal data is written only to the CRM record and the authenticated API, never to logs or public output.
Approval policy routes named actions through the approval engine instead of running them: which actions need approval, who receives the queue, and how many hours an approval may wait before it escalates, 24 by default. Execution policy is a hard runtime gate: runs per hour, a daily cost cap and a per-action cap, enforced by the runtime and not by the model.
Budget and approval authority complete the wrapper. Spending is a part of the agent, not a report produced afterwards. Approval authority names the people who may override a verdict for this agent, with role-based permission as the fallback, and learning mode decides how operator decisions land: continuous adaptation, or a training window in which every action is queued.
The same unit composes upward
An agent is the smallest governed unit, and everything above it is built from the same primitive rather than a separate abstraction.
| Layer | What it is |
|---|---|
| Agent | Ten declared parts, its own guardrails, policies and budget, and a trust record rebuilt nightly |
| Reporting line | One agent key names a parent. Hand-offs follow the line, so an org chart change reroutes work without editing any agent |
| Team | People and agents in one thread with a lead agent and a shared record of charter, roster, decisions and runs. Membership is the access boundary |
| Workflow | Versioned graphs of agent, branch, parallel, join and loop nodes, with a blast radius panel that flags a third-party call at design time |
| Control plane | Live operations, topology, governance and anomalies read every unit through the same declared parts, which is what makes a fleet legible rather than merely large |
Configuration is the argument
An agent built as a program is a liability the moment its author leaves. An agent built as a configuration is an asset a new operator can read, audit, adjust and retire on their first day.
That is the whole claim behind the anatomy: ten parts, each with a stored value, an owner and a history. It is what lets autonomy be granted in increments rather than in one act of faith, and it is why the question at deployment stops being whether the model is good enough and becomes which settings this particular piece of work deserves.
To see how other agent platforms handle the same parts, the comparison hub sets Nagent beside each one with dated screenshots and sources, and the guide to evaluating an agentic AI platform turns these ten parts into questions for a vendor.
Frequently asked questions
Why describe an agent as a configuration rather than a program?
A program can only be read by the engineer who wrote it. A configuration can be read by everyone who has to sign it off: security reads the tool list and guardrails, finance reads the budget, operations reads the triggers and the reporting line. Changes become settings with an owner and a history instead of releases.
What are the ten parts of a Nagent agent?
Triggers decide when it wakes. The model does the reasoning. Memory holds what worked and what did not. Skills are attached procedures. Trust is a score rebuilt nightly. Autonomy is the level it holds. Tools and external tools are the actions it may take. Budget caps its spend. Surfaces are the records it leaves for colleagues.
What decides whether an agent's action actually happens?
Three independent settings. Whitelisting decides whether the action exists for that agent at all. Autonomy decides whether a whitelisted action runs now or waits for a person. Triggers decide when the agent runs in the first place. Granting a send action never sends anything on its own.
How is a new ability added to an agent?
By attaching something to a declared part rather than editing code: a skill from the shared catalogue, a tool granted by action key, a new output type on its surfaces, or a place on the reporting line. Each attachment is reversible and appears on the agent's profile the moment it is saved.
Where do guardrails and budgets live?
On each agent, not on the fleet. Every agent carries its own guardrails, approval and execution policies and spending caps, drawn from a shared template library. Caps are enforced by the runtime rather than requested of the model, and a breach queues work for approval instead of losing it.
How do agents compose into teams and workflows?
The agent is the smallest governed unit and everything above it reuses it. A reporting line routes hand-offs, a team puts people and agents in one thread with a shared record, and a workflow is a versioned graph of agent nodes that reports its blast radius at design time.
Sources
- Nagent documentation, what an agent is https://nagent.ai/docs/what-is-an-agent
- Nagent documentation, autonomy and governance https://nagent.ai/docs/autonomy-and-governance
- Nagent documentation, skills https://nagent.ai/docs/skills
- Nagent documentation, triggers and webhooks https://nagent.ai/docs/triggers-and-webhooks
- Nagent documentation, credits and budgets https://nagent.ai/docs/credits-and-budgets
- Nagent documentation, creating an agent https://nagent.ai/docs/creating-an-agent
Cite this page
Plain:
Nagent AI. Anatomy of an Agent: A Configuration, Not a Program. Frameworks, no. 2. 2026. https://nagent.ai/artefacts/anatomy-of-an-agent
BibTeX:
@misc{nagent2026anatomyofanagent,
author = {Nagent AI},
title = {Anatomy of an Agent: A Configuration, Not a Program},
series = {Frameworks},
year = {2026},
url = {https://nagent.ai/artefacts/anatomy-of-an-agent},
note = {Published 2026-10-04, updated 2026-10-04}
}The direct answer at the top of this page is written to be quoted as one sentence with this URL as its source.
About Nagent
Nagent is Multiplayer AI for end to end growth: a team of AI coworkers and your own people, working together in one workspace across marketing, sales and customer experience. Three things make it different. You approve the AI coworkers' work until they earn the right to act on their own. They carry the work all the way to pipeline and customers, not just content. And where your plan includes it, a Nagent marketer joins your team and owns the number with you. Founded in Bengaluru in 2024, Nagent is an Anthropic partner, holds four filed patents on orchestration and memory, and deploys in the customer's private cloud.
Published 4 October 2026. All rights reserved. Quote with attribution to Nagent AI and a link to this page.
