# Lean AI agent profile checklist

Version: 1.0
Updated: 2026-07-29

Purpose: reduce fixed context and capability sprawl without removing the tools, evidence, or safety boundaries an agent needs for its actual job.

Output: one before-and-after profile record with a justified capability set and three comparable latency checks.

## Use when

An agent feels slow, overcomplicated, too eager to use tools, or loaded with capabilities unrelated to its job.

This checklist helps separate four different questions:

1. How large is the fixed context?
2. Which capabilities are actually required?
3. Where does end-to-end latency occur?
4. Does the leaner profile still complete its core work safely?

## 1. State the profile job

Complete this sentence before pruning anything:

> This profile exists to [primary job] through [control surface], using [required systems], within [authority boundary].

- Profile name:
- Primary job:
- Primary operator:
- Control surface:
- Required systems:
- Allowed actions:
- Actions requiring approval:
- Explicitly out of scope:

If the profile has several unrelated primary jobs, split the jobs before optimizing the prompt.

## 2. Capture the before-state

Use the runtime's supported inspection command. For Hermes:

```sh
hermes -p PROFILE prompt-size --platform telegram --json
```

Record counts and sizes, but redact credentials, private paths, user identifiers, and raw configuration values.

| Fixed layer | Before | Notes |
|---|---:|---|
| System prompt characters or tokens |  |  |
| Enabled skills |  |  |
| Skills-index characters or tokens |  |  |
| Tool schemas |  |  |
| Serialized tool-schema bytes or tokens |  |  |
| Memory characters or tokens |  |  |
| User-profile characters or tokens |  |  |
| Platform-specific instructions |  |  |

These figures describe fixed context. They do not by themselves prove why an end-to-end reply is slow.

## 3. Inventory capabilities by need

| Skill or tool group | Required every week | Required occasionally | Not part of this job | Keep / disable / load on demand |
|---|---|---|---|---|
| Files and shell |  |  |  |  |
| Web search or retrieval |  |  |  |  |
| Source control |  |  |  |  |
| Messaging |  |  |  |  |
| Browser control |  |  |  |  |
| Documents and office tools |  |  |  |  |
| Images, audio, or video |  |  |  |  |
| Schedules and monitoring |  |  |  |  |
| External publishing |  |  |  |  |
| Other |  |  |  |  |

For each capability kept, write one representative task that requires it. "It may be useful someday" is not a representative task.

## 4. Remove duplication and repetition

- [ ] One tool owns each external system unless a tested fallback is intentional.
- [ ] The identity prompt does not repeat framework policy.
- [ ] Stable project rules live in one authoritative place.
- [ ] Memory contains durable facts, not complete task transcripts.
- [ ] Unrelated skill packs are disabled or loaded on demand.
- [ ] Automatic skill seeding is understood and intentionally configured.
- [ ] Safety and approval boundaries remain explicit.

## 5. Establish comparable latency checks

Run the same three prompts before and after the change. Keep the model, provider, reasoning setting, channel, and network path unchanged.

| Test | Example shape | Before | After | Notes |
|---|---|---:|---:|---|
| Direct answer | one factual sentence, no tools |  |  | time to first visible text |
| Reasoning answer | one bounded comparison |  |  | total response time |
| Representative tool task | one required tool, one observable result |  |  | tool and delivery time |

Do not compare different models or tasks and attribute the whole difference to prompt size.

## 6. Apply one bounded change

- Change:
- Expected reduction:
- Required capability that must remain:
- Rollback:
- Restart or reload method:

Change one capability group at a time. A large batch makes it harder to identify which removal helped or which removal broke the job.

## 7. Capture the after-state

| Fixed layer | Before | After | Difference |
|---|---:|---:|---:|
| System prompt characters or tokens |  |  |  |
| Enabled skills |  |  |  |
| Skills-index characters or tokens |  |  |  |
| Tool schemas |  |  |  |
| Serialized tool-schema bytes or tokens |  |  |  |
| Memory characters or tokens |  |  |  |
| User-profile characters or tokens |  |  |  |

## 8. Verify the real operating path

- [ ] Direct reply matches the intended tone and length.
- [ ] The representative tool task still succeeds.
- [ ] Required model and provider are active.
- [ ] Messaging or API channel delivers the result.
- [ ] User allowlist or access control still holds.
- [ ] Approval gates still interrupt consequential actions.
- [ ] Errors identify the failing layer rather than returning false success.
- [ ] The configuration survives a supported restart.

## 9. Decide

Choose one:

- **Keep:** the profile is smaller and still passes its core operating checks.
- **Iterate:** the profile works, but another clearly unrelated capability group remains.
- **Roll back:** a required capability, safety boundary, or recovery path failed.
- **Inconclusive:** the measurements changed too many variables to assign cause.

## Stop conditions

Stop and ask before continuing if:

- the runtime does not expose enough information to identify what will be removed;
- a proposed change weakens access control, secret handling, approval, or audit evidence;
- the only available test would expose a credential or private configuration;
- different models, providers, channels, or tasks make the before-and-after comparison invalid;
- the profile cannot be restored through a tested rollback.

## Evidence record

- Date:
- Runtime and version:
- Model and provider:
- Profile job:
- Before report:
- Change applied:
- After report:
- Three latency checks:
- Core-task proof:
- Restart proof:
- Decision:
- Next review trigger:

Related method: [Why my new AI agent was slow before it answered](https://suhailmohebi.com/notes/ai-agent-prompt-bloat/)