Why my AI agent was slow: 61 skills and 27 tool schemas

My new agent was carrying 61 enabled skills and 27 tool schemas before it read my first instruction.

The delay started before the task

The agent’s assembled system prompt was about 18,000 characters, and the serialised tool definitions added roughly 47 KB outside that text. A short personality prompt could change its tone. It could not remove the layers the framework owns.

The size showed the profile was not lean, though on its own it could not explain the delay. Model speed, provider routing, reasoning effort, retries, network conditions, tool calls and session state all stayed on the list of possible causes. I could measure the fixed prompt directly, while the slow reply was a symptom of the whole request path, so I kept the two questions apart.

Measure the fixed prompt the runtime sends

At first I looked only at 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, this command reports the size of each part of the fixed prompt:

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

The exact output changes with the runtime version and configuration. The categories to read are the base system instructions, the enabled-skill index, memory, the user profile, platform-specific instructions, the tool count and the serialised tool schemas. I measure them together before deciding that the model is slow or that the personality prompt needs another rewrite.

The runtime assembles several layers before the first user message arrives.

1. Runtime policyCore behaviour, safety, file, memory and platform instructions.
2. IdentityThe profile prompt that defines role, tone and working style.
3. Skills indexDescriptions of capabilities the model may decide to invoke.
4. Tool schemasNames, arguments, descriptions and response contracts.
5. MemoryStored facts or retrieved context added for continuity.
6. ConversationThe current message and earlier turns enter the stack last.

What the new profile was carrying

I compared the new Telegram profile with the main profile on the same live runtime. The figures are one diagnostic snapshot from 29 July 2026 and describe only my two profiles. Character counts and serialised bytes let me compare the profiles, but they are not model-token counts or billing figures.

The 18,000-character total mattered less than the overlap. An agent meant for one job carried almost the same tools as the general agent, plus dozens of skills unrelated to that job. The profile was separate in name, but its capabilities had barely been narrowed.

The heavier agent felt faster

The main profile had a larger fixed text prompt and still felt faster in use. That counted against my first theory: if prompt size alone explained the delay, the new profile should have felt faster.

The end-to-end delay can have other parts:

• 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 behaviour: the agent may inspect, select or call a tool before it answers.
• Retries and fallbacks: a failed attempt that never shows in the chat can make the successful reply after it look 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.

Tool schemas stay when the personality shrinks

I still wanted the new agent to be as direct as my main one, so I wrote a concise identity prompt. It removed ceremonial language, over-explanation and automatic planning from ordinary replies. That changed its behaviour.

The prompt left what the agent could load untouched. 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 the framework. Repeated prompt edits can make the visible instructions shorter while the fixed context stays nearly the same size.

For current runtime behaviour, check the public Hermes Agent repository. My measurements describe my own profile as it was configured on the day I measured it.

The lean profile I want

A Telegram coding agent with one job needs fewer capabilities than a general research assistant. I define its profile by that job and enable only the framework features the job uses.

1. One primary job: coding and technical operations from a private Telegram bot.
2. A small default toolset: files, shell, search and the few remote operations the job requires.
3. Skills loaded by need: keep recurring coding and verification skills; disable unrelated media, office, social and publishing skills.
4. One tool per system: if two tools reach the same system, keep the one I use.
5. Minimal memory: keep stable preferences and operating limits, and leave out a log of every finished task.
6. Explicit safety limits: approval gates and secret handling stay in the lean profile.
7. Observable performance: record profile size and simple latency checks after each material change.

I turned those decisions into a lean AI agent profile checklist. It covers pruning a profile while keeping the checks and safety controls that make it trustworthy.

Prove the change with a before-and-after measurement

I count an edit as finished when the profile is smaller, behaves as intended, still completes its core tasks and comes back the same after a restart. A saved config or a restarted gateway shows none of those things.

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 confirm the lean configuration persists.

Keep bot tokens, provider credentials, private paths and complete raw configurations out of the test record. If a bot token reaches a chat, issue, screenshot or public log, rotate it; deleting the message leaves the token valid.

Questions I would ask first

Suhail Mohebi · published 29 July 2026 · the cover is a generated illustration