Skip to content
NagentNagent
Log inSign upHire your AI team
Frameworks no. 2

Anatomy of an Agent: A Configuration, Not a Program

The ten declared parts every Nagent agent is built from

What is an AI agent made of?

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.

PartWhat it holdsWhat changes when it changes
TriggersSchedules and named events that wake the agentWhen it works; nothing about what it may do
ModelThe reasoning model, set per agent over the platform defaultCost and speed per run, never its permissions
MemoryOperator rules and brand voice, plus its own record of what worked and what failedWhat it knows before every run
SkillsAttached procedures, each with a priority weightHow it approaches repeat work
TrustA score out of 100, rebuilt nightly from five signalsHow much autonomy it can hold
AutonomyThe level it holds, from locked to fully autonomousWhether a permitted action runs now or waits
ToolsThe platform actions it may invoke, enforced by scopeWhat it can do inside the workspace
External toolsActions in outside systems, granted one key at a timeWhat it can reach beyond the workspace
BudgetDaily and monthly caps in currency, enforced by the runtimeHow much it may spend, and what happens on breach
SurfacesThe record types it may write: finding, analysis, plan, draft, resultWhat 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.

The skills catalogue in a Nagent workspace: each skill with its key, a priority weight, a version and the agents it is attached to

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.

PartCustomer state agentOutbound sales agentBlog writer
TriggersEvent driven, no scheduleReply and stage eventsA schedule
ModelA small, fast modelPlatform defaultPlatform default
MemoryOn, continuous learningOn, continuous learningOn, continuous learning
SkillsFive, scoring and analysisOutreach composer, reply classifierSourced drafting
Trust and riskMedium riskHigh riskMedium risk
AutonomyAudit onlySuggest only, while its record is builtExecute with approval
Tools19 of 102, scope enforcedResearch, CRM writes, sendKnowledge base search
External toolsWhitelist enforcedContact enrichment, email deliveryNone
Budget5 USD a day, 100 USD a monthNot cappedNot capped
SurfacesFinding, analysis, plan, draft, resultDraft, resultDraft
Reporting lineNone, it is a root agentReports to the sales lead agentReports to the content lead agent
GuardrailsFour, three of them blockingApproval before any external emailBanned 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.

The Nagent agent builder: describe the agent in one line, answer a few questions, and review a complete agent with skills, tools, triggers and guardrails

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.

LevelFires without askingQueues for approvalWhat the person does
LockedNothingAll work, including read-only analysisActs on every output. Used for a first week in production or an agent under review
Suggest onlyRead-only work: research, scoring, synthesisEverything with a side effect. Drafts are visible and never sent on their ownReads the drafts and sends what is good
Execute with approvalRead-only work, and anything already approved in patternEach side-effecting action, one at a time, before it runsSigns off; the approval queue carries a deadline in hours
Audit onlyThe full remit, logged for reviewOnly actions caught by a blocking guardrail or an approval policyReviews after the fact and overrides where needed. Every override feeds trust
Fully autonomousEverything the whitelist permitsNothing by default. Guardrails and budget caps remain the brakesWatches 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.

  1. Attach a procedure. Skills come from the catalogue with a priority weight and are attached without touching the agent.
  2. Grant an action. Tools are granted by action key and enforced by scope. Fewer tools mean a shorter prompt and fewer wrong choices.
  3. Declare an output type. Surfaces name the records an agent may write and how each renders on the team board.
  4. 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.

LayerWhat it is
AgentTen declared parts, its own guardrails, policies and budget, and a trust record rebuilt nightly
Reporting lineOne agent key names a parent. Hand-offs follow the line, so an org chart change reroutes work without editing any agent
TeamPeople and agents in one thread with a lead agent and a shared record of charter, roster, decisions and runs. Membership is the access boundary
WorkflowVersioned graphs of agent, branch, parallel, join and loop nodes, with a blast radius panel that flags a third-party call at design time
Control planeLive 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

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.

Nagent · Multiplayer AI for growth teamsResearch: 21–29 September 2026 · Public-source analysis, no hands-on benchmark · Sources & method