Agent terminated due to error

[aliensarcoskuner-new]

What kind of help do you need?

Other

Your question

When I mention a skill
Example : @build-native-ui or any skill
Agent crashes. Always.
I didn't hit my quota limit but it crashes I dont know why. I can't mention a skill.

Environment and context

No response

What have you already tried?

Reboot

Before posting

• I checked the README, FAQ, and relevant docs first.

[sickn33]

Thanks for reporting this. This sounds similar to the known truncation/context-overflow issue that can happen when an IDE/integration loads too many skills into one prompt at startup, but I can’t confirm that yet from the current details.

Could you share:

the exact error text or a screenshot of the prompt error,
your OS,
whether you installed the full library or only a small subset of skills,
whether this is happening in the IntelliJ/IDEA integration specifically.
As a quick workaround, please try loading only a few skills instead of the full library, or use the activation script to keep only the bundles you need active at once.

If you are on Windows and Antigravity keeps reopening into the same broken session, please also check the truncation recovery steps here:

README: Windows truncation/context crash loop
docs/users/windows-truncation-recovery.md
If you can post the exact error, I can tell you whether this is the same truncation issue or something new

[karnaensusilo977-alt]

"Could we implement a global orchestrator skill (or router skill), with all subordinate skills placed in subdirectories? This global skill would be responsible for evaluating which specific skills need to be triggered, and it would enforce a strict invocation cap of 30-40 per execution. Is this a viable architecture?"

[sickn33]

@AnthoniusHendriyanto thanks, this is very helpful. That TrajectoryChatConverter: could not convert a single message before hitting truncation stack confirms this is the same startup/context-overflow class of issue, not a skill-specific crash.

@karnaensusilo977-alt a global router/orchestrator can be a viable architecture, but only if it sits on top of a lightweight manifest and lazy-loads child SKILL.md files on demand. If the host still scans or injects the full library at startup, adding an orchestrator does not solve the problem and can actually increase the initial payload.

So the safe pattern is:

• bootstrap from a small manifest/index
• resolve explicit @skill-id mentions or matched skills
• load only those selected skills for the current turn
• enforce a hard per-turn cap/token budget

That is also why the current workaround is still to activate only a small subset of bundles/skills instead of the full library at once. I added docs for both paths here:

• docs/users/agent-overload-recovery.md
• docs/integrations/jetski-cortex.md

So short answer: yes to orchestration as a routing layer, no if it still means preloading all subordinate skills into one prompt.

[AnthoniusHendriyanto]

This is the same issue I encountered @sickn33 on Windows and Ubuntu. After installing the full library, I ran into this problem, and once the agent crashed, I couldn’t retry or use it anymore.

To fix it, instead of installing the full library, I installed the dependencies one by one or I used npx antigravity-awesome-skills --gemini and selected only the Gemini option.

The Error

Trajectory ID: 50d93ccf-fd1c-44df-9096-d8f2f4e56d55
Error: agent executor error: could not convert a single message before hitting truncation
(1) attached stack trace
  -- stack trace:
  | google3/third_party/jetski/cortex/cortex.(*CascadeManager).executeHelper.func1
  | 	third_party/jetski/cortex/cascade_manager.go:2088
  | [...repeated from below...]
Wraps: (2) agent executor error
Wraps: (3) attached stack trace
  -- stack trace:
  | google3/third_party/jetski/cortex/chatconverters/chatconverters.init
  | 	third_party/jetski/cortex/chatconverters/trajectory_chat_converter.go:44
  | runtime.doInit1
  | 	third_party/go/gc/src/runtime/proc.go:8105
  | runtime.doInit
  | 	third_party/go/gc/src/runtime/proc.go:8072
  | runtime.main
  | 	third_party/go/gc/src/runtime/proc.go:258
  | runtime.goexit
  | 	third_party/go/gc/src/runtime/asm_amd64.s:1774
Wraps: (4) could not convert a single message before hitting truncation
Error types: (1) *withstack.withStack (2) *errutil.withPrefix (3) *withstack.withStack (4) *errutil.leafError

I hope this helps to fix the problem

[sickn33]

Thanks, this gives us the exact failure signature.

This is the known truncation/context-overflow case, so the fix is usually to both clear the broken stored session and reduce the active skill set.

For Windows:

1. Fully close Antigravity.
2. Remove the large/full skill install from %USERPROFILE%\.gemini\antigravity\plugins\skills if that path exists in your setup.
3. Clear the stored session folders:
   • %USERPROFILE%\.gemini\antigravity-browser-profile\Default\Local Storage
   • %USERPROFILE%\.gemini\antigravity-browser-profile\Default\Session Storage
   • %USERPROFILE%\.gemini\antigravity-browser-profile\Default\IndexedDB
   • %AppData%\antigravity\Local Storage
   • %AppData%\antigravity\Session Storage
4. Restart Antigravity.
5. Reinstall only a small subset instead of the full library.

For Ubuntu/Linux:

1. Fully close the host/IDE.
2. From a clone of this repo, activate only a few bundles or skill ids instead of the full library:
   ./scripts/activate-skills.sh --clear Essentials
   or
   ./scripts/activate-skills.sh brainstorming systematic-debugging
3. Reopen the host after that smaller active set is in place.

If you are using the Gemini CLI installer path, your workaround is the right one: npx antigravity-awesome-skills --gemini plus a smaller selected set is the safe route.

Longer-term fix for integrations: do not preload every SKILL.md at startup. Use a lightweight manifest like data/skills_index.json, then lazy-load only the skills explicitly referenced for that turn, with a hard max skills/token budget.

I documented the recovery paths here if you want the exact steps:

• docs/users/windows-truncation-recovery.md
• docs/users/agent-overload-recovery.md
• docs/integrations/jetski-cortex.md

If you want, I can also add a short “Ubuntu crash-loop recovery” section to the docs so the Linux path is as explicit as the Windows one.

[furkancvk]

Could you please add recovery for Linux/Ubuntu

[sickn33]

@furkancvk yes, that should be documented more explicitly for Linux/Ubuntu too.

For Linux/Ubuntu, the practical recovery path is:

1. Fully close Antigravity.
2. Keep the full library archived instead of exposing every skill at once.
3. From a local clone of this repo, activate only a small subset into the live Antigravity directory.

Examples:

./scripts/activate-skills.sh --clear Essentials
./scripts/activate-skills.sh --clear "Web Wizard"
./scripts/activate-skills.sh brainstorming systematic-debugging

What this does:

• keeps the full library in ~/.gemini/antigravity/skills_library
• activates only the selected bundle/skills into ~/.gemini/antigravity/skills
• reduces the startup/context load that causes the truncation failures

The guide for that flow is here:
docs/users/agent-overload-recovery.md

So short version: on Linux/Ubuntu, the fix is usually not “reinstall everything again,” but “switch from full live exposure to a much smaller active subset.” That is the safest path until the host lazily loads skills instead of preloading a huge tree.