Why my new AI agent was slow before it answered

§1The delay started before the task

My new agent was carrying 61 enabled skills and 27 tool schemas before it read the first useful instruction. Its assembled system prompt was about 18,000 characters, while the serialized tool definitions added roughly 47 KB outside that text. A short personality prompt could change its tone, but it could not remove those framework-owned layers.

That did not prove prompt bloat was the only cause of the delay. It proved the profile was not lean. Model speed, provider routing, reasoning effort, retries, network conditions, tool calls, and session state still had to remain in the diagnosis.

§2Measure the fixed prompt, not the reply length

I had initially focused on the visible prompt: the identity, style, and instructions I had written for the new profile. The runtime was assembling much more than that. In Hermes, the useful inspection is:

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

The exact output changes by runtime version and configuration, but the categories matter: base system instructions, enabled-skill index, memory, user profile, platform-specific instructions, tool count, and serialized tool schemas. Measure them together before deciding that the model is slow or that the personality prompt needs another rewrite.

§3What the new profile was carrying

I compared the new Telegram profile with the main profile on the same live runtime. The figures below are one diagnostic snapshot from 29 July 2026, not a universal benchmark. Character counts and serialized bytes are useful for comparison; they are not exact model-token counts or billing figures.

The useful finding was not “18,000 characters is too many.” It was that a supposedly focused agent had almost the same tool surface as a general agent and dozens of skills unrelated to its immediate job. The profile boundary existed in name, but not yet in capability.

§4The heavier agent felt faster

The main profile had a larger fixed text prompt and still felt faster in use. That was important disconfirming evidence. If prompt size alone explained the experience, the order should have been reversed.

End-to-end latency can also include:

• Model and provider: first-token latency and generation speed vary across models, routes, and current load.
• Reasoning policy: a model asked to deliberate longer may pause before producing visible text.
• Tool behavior: the agent may inspect, select, or call a tool before it answers.
• Retries and fallbacks: an invisible failed attempt can make one successful reply look mysteriously slow.
• Session state: a warm, established session and a new profile may take different paths.
• Gateway and network: Telegram delivery adds another system boundary after model inference.

§5A shorter personality does not remove tool schemas

I still wanted the new agent to match the directness of my main one, so a concise identity prompt was useful. It removed ceremonial language, over-explanation, and automatic planning from ordinary replies. That is a behavior change.

It was not a capability change. Rewriting “be concise” cannot unload a media-generation skill, remove a calendar tool, stop an automatic skill seed, or shrink a schema injected by the runtime. Those controls live in the profile configuration and framework. The distinction matters because repeated prompt edits can make the visible instructions shorter while the fixed context remains nearly unchanged.

The public Hermes Agent repository is the appropriate reference for current runtime behavior. My measurements describe my configured profile at one point in time.

§6The lean profile I actually want

A focused Telegram coding agent does not need every capability that a general research assistant might use. Its lean profile should be defined by a job, not by the full list of features the framework can expose.

1. One primary job: coding and technical operations from a private Telegram control surface.
2. A small default toolset: files, shell, search, and the few remote operations that the job genuinely requires.
3. Skills loaded by need: keep recurring coding and verification skills; disable unrelated media, office, social, and publishing skills.
4. No duplicate contracts: if two tools reach the same system, choose the one the operator actually uses.
5. Minimal durable memory: keep stable preferences and operating boundaries, not a transcript of every successful task.
6. Explicit safety boundaries: lean does not mean unguarded. Approval gates and secret handling stay.
7. Observable performance: record profile size and simple latency checks after each material change.

I turned those decisions into a reusable lean AI agent profile checklist. It is designed for pruning a profile without accidentally removing the evidence and safety controls that make it trustworthy.

§7Prove the change instead of trusting the new prompt

A successful edit is not “the config saved” or “the gateway restarted.” The profile should be smaller, behave as intended, still complete its core tasks, and return after a restart.

1. Capture the before-state with the prompt-size report and a redacted profile inventory.
2. Disable one group of unrelated skills or tools.
3. Restart only the affected profile or gateway using its supported control path.
4. Capture the after-state with the same report.
5. Time a direct no-tool answer, a reasoning answer, and one representative tool task.
6. Verify the Telegram path, allowlist, model identity, and required tool still work.
7. Restart once more and prove the lean configuration persists.

Do not paste bot tokens, provider credentials, private paths, or complete raw configurations into the evidence record. If a bot token reaches a chat, issue, screenshot, or public log, rotate it rather than treating deletion as recovery.

§8Questions I would ask first