# Automation Limitations & Solutions

* Heterogeneous data & domain tasks: Specific architecture designs must be considered when integrating multiple AI agents. Many orchestration systems are optimized for text/LLM tasks, not for domain-specific pipelines (e.g. data analytics, statistical tests). You’ll often have to glue your domain tools manually.
  * *<mark style="color:$warning;">If I could complete the self-orchestrated lifecycle during the data cleaning stage, that would be great.</mark>*
* Error recovery & rollbacks: When an agent fails or returns an invalid result, robust systems need mechanisms to retry, fallback, or roll back. That’s still a weak area in many frameworks.
  * Possible solutions:
    * Reset LLM caches - not many realise that calling LLMs with certain servers actually defaults the models to use past caches to generate responses. While this is efficient, the llm is bound to overfitting to irrelevant chat contexts and may persist chats across chat sessions (worst case ⇒ data leakage during multiple chat windows with different users). Knowing when to reset the caches is ideal. Considering caches management indepdent from ranking the caches (to persist or influence next responses) is not a scalable solution. So, the possible ways in solving this would be 1) define concrete method on prioritizing the key-value caches after each chat session (still open problem), and 2) defining rule set to dispose chat caches. I am guessing step 2 should fall into place once the previous is done.
* Resource coordination: If agents use GPUs, memory, or expensive model calls, orchestration must juggle resource allocation. Systems like Murakkab try this, but it’s still early days.
  * Possible solutions:
    * Cache management strategy as mentioned in the previous point.
    * Model Quantization / Compressing lifecycle. A robust framework that runs on a scheduled basis for e.g.&#x20;
      * after a specific data batch size is reached (from observations & human interaction) -> fetch this current chat stream's insights to define the fine-tuning parameters conditioned to current dataset -> fine-tune base model-> run sampling strategies + evaluation loop to get the optimal performance on test results -> compare with pre-configured rules to define the GGUF params -> compress the model
* Trust, transparency & debugging: Interpreting *why* the orchestrator chose a path or agent is often black-box.&#x20;
  * Possible solutions:
    * Transparent view of agent's working terminal. Dataset collected: Loggings of each action + model's response output + caches management. This dataset would require a human user to analyze though.
    * Implement cloud setup with best practices e.g. logs, audit trails, explanations.
    * Many, many test cases.
* Scalability vs latency: More agents + more checks = more overhead. There’s a trade-off between depth and speed. Distributed orchestration (like in Symphony) shows promise but has complexity.
  * Same solutions as ones referring to cache management.
* Decentralized orchestration is still experimental. Most systems still rely on a central orchestrator node (a single control brain). The decentralized versions (like Symphony) are new, not battle-tested in production.
  * Possible solutions:
    * Setup must be distributed over different cloud services and containers. Hence, dockers containers are used as the fundamental frameworks for my agents - you can define volume / network / environment / containers all in one. What a great time to be alive.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://whoamimi.gitbook.io/blog/projects/readme-1/backend-api/automation-limitations-and-solutions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.