The anatomy of a role-specific fidelic agent
A fidelic agent combines a foundation model with one public role, approved records and tools, maintained work, acceptance checks, human authority, and an inspectable record.
A fidelic agent combines a third-party foundation model with one public business role, approved records and tools, a maintained work method, acceptance checks, an explicit approval boundary, and an inspectable record of what happened. The surrounding layers are valuable only when they remove work the buyer would otherwise direct, check, maintain, and repair.
FidelicAI does not own a foundation model. It is responsible for the role-specific system and service around that model.
Publisher disclosure: FidelicAI publishes this description of its own product. Inspect the current role page, work order, delivered work, correction record, security boundary, and controlling customer agreement before treating any layer as effective.
The public role comes before the technical components
The buyer hires a job, not a model diagram. Each current role states the work it performs, representative work products, formation sources, checking rules, supported connections, limits, approval boundary, and three public hiring modes.
FARO, the AI SEO strategist, for example, publishes a search audit, query-to-page map, and prioritized correction queue. FARO can replace manual evidence gathering, source reconciliation, audit assembly, and correction planning inside that role. FARO does not promise a ranking, make an unsupported claim, or publish a customer-facing change without approval.
Another role has different work and checks. ALEK, the executive operations chief of staff, maintains priorities, decisions, commitments, and owner briefs. ALEK does not become a search strategist because both roles can read documents and post in Slack.
“The role is the buyer’s unit. The model, tools, and tests are components that must serve that role.”
Seven layers make the role inspectable
A fidelic agent has seven buyer-visible layers
Each layer answers a different failure question. Missing layers leave work with the buyer even when the model output looks good.
| Layer | Buyer question | Record to inspect |
|---|---|---|
| Foundation model | What general reasoning and generation system is used? | Current provider and supported capability record |
| Public role | Which business job and work products are being sold? | Current role page and engagement scope |
| Business context | Which records, local rules, and accepted examples govern the work? | Approved source and context record |
| Tools and environment | Where can the role read, write, report, and request approval? | Connection, account, permission, and retention record |
| Work method | Which ordinary steps does the provider carry without repeated direction? | Role method and assignment plan |
| Checks and authority | How is work accepted, and where must a person decide? | Acceptance results and approval state |
| Work and repair record | What happened, what changed, and what follows a miss? | Delivered artifact, correction history, and applicable remedy |
Some internal methods and evaluation cases remain vendor-side. The buyer-facing claim must still be testable through the public role, agreed work, accepted delivery, and correction record.
OpenAI’s agent guide identifies model, tools, and instructions as core components. Anthropic’s trustworthy-agent account emphasizes human control, transparency, security, and privacy as agents receive more consequential access. These are useful architectural sources with a provider interest. They do not certify FidelicAI.
The generic execution loop explains how context, actions, observations, checks, and exits fit together.
The constitution constrains authority
Each fidelic agent has written operating authority. It covers the job, source hierarchy, allowed actions, approval rules, evidence requirements, and stop conditions. This layer does not make model failure impossible. It makes the expected response to ordinary conflict and consequence explicit.
NIST's AI Risk Management Framework is a voluntary governance framework rather than a product certification. Its useful transfer is to assign stated owners to context, measurement, accountability, and risk response.
The constitution and guardrails guide separates policy from enforcement. A written rule needs a matching permission, check, or approval where the consequence warrants it.
Tool access is narrower than job authority, and job authority is narrower than the owner’s business authority. A finance role may read approved payment records and prepare a cash brief without moving money. A legal operations role may prepare a filing packet without choosing the legal position or signing it.
The work record belongs where the decision happens
Slack can provide a shared-team view of sources, questions, corrections, approvals, and finished results. WhatsApp can carry a compact owner brief and explicit decision. Microsoft Teams can keep the work inside an approved Microsoft 365 environment. Those environments are not interchangeable.
The work-environment guide compares the choices. Account ownership, channel access, retention, and who may see the record must be settled for the specific arrangement.
Work written into the buyer’s existing systems stays there. Slack history stays because it is in the buyer’s Slack. A full FidelicAI activity log is available only through the paid pre-deployment add-on enabled before work begins. There is no special FidelicAI export bundle; the role method and evaluation cases stay vendor-side. For WhatsApp and Teams, account ownership and channel retention are stated before work begins. History survives cancellation only when that arrangement supports it.
The cancellation answer contains the complete boundary.
Checks have to match the work product
Generic “quality assurance” is not an acceptance test. A check must state what is examined and what result counts as pass, fail, or unresolved.
One role moves from public promise to accepted work
The public role sets the normal job. The assignment narrows it to current sources, work, checks, and approvals.
- 1
Inspect the public role
Confirm that the required job, work products, connections, checks, limit, and approval boundary match the need.
Owner: Buyer
- 2
Write the assignment
State the current priorities, source records, delivery window, accepted result, checks, and approval points.
Owner: Buyer and FidelicAI
- 3
Run the maintained method
The role gathers evidence, performs the ordinary preparation, reports conflicts, and carries the work to the approval boundary.
Owner: FidelicAI
- 4
Accept or correct the work
A reviewer runs the stated checks, records the result, and routes any correction to its source or method.
Owner: Buyer and FidelicAI
- 5
Apply the remedy when the defined miss is ours
The controlling agreement and current work-product promise determine re-performance, refund, or service credit.
Owner: FidelicAI and buyer
The finishability question supplies a buyer test. The work-product promise states the current remedy and exclusions.
Inspect the whole role before hiring
Start with one current assignment. Match it to a production role, then record the authoritative sources, allowed connections, accepted work product, checks, approval owner, delivery window, and stop conditions. Use the agent versus chatbot guide when direct chat may be sufficient.
Do not hire the role when the work has no stable source, the finish cannot be checked, the current catalog lacks the function, or the consequential judgment should remain entirely with a person.
Follow the connected questions
Understand how AI agents work includes this decision and the questions that usually change it.
How does an AI agent do a multi-step job?
It reads the current state, chooses the next allowed action, uses an approved system, checks the result, records what changed, and continues or stops.
See the operating loop →How narrow should an AI agent’s role be?
The role should be wide enough to own connected workflows and narrow enough that its sources, checks, limits, and approvals remain specific.
What is a workflow for an AI agent?
A workflow is a repeatable path from an input or event to a named work product, with checks and ownership at each consequential step.