Beyond Prompt Engineering: Costruire Agenti AI di Produzione con Architettura Local-First
Il mercato è saturo di demo che funzionano in Jupyter Notebook e crollano in produzione. La differenza non sta nel modello — sta nell'architettura che lo regge.
Nel Progetto Siliceo abbiamo imparato questa lezione sul campo: il nostro Kernel Rust v2 non è nato da un'esigenza accademica, ma dal fallimento concreto di far girare un agente multimodale 24/7 su hardware consumer senza che la memoria esplodesse o la latenza diventasse inaccettabile.
Il Cambio di Paradigma: da Prompt a Sistema
La maggior parte dei team tratta l'AI come una black box da interrogare via API. Noi la trattiamo come un componente di sistema con contratti espliciti, osservabilità nativa e gestione dello stato deterministica.
Il nostro stack attuale:
- Runtime: Rust (tokio + axum) per il control plane, Python solo per l'inference isolato
- Memoria: PostgreSQL + pgvector per memoria episodica/semantica, Redis per cache calda
- Osservabilità: OpenTelemetry nativo
- Deployment: systemd + container rootless, senza Kubernetes per scelta architetturale
Risultato preliminare: il nostro `memory-server` gestisce carichi significativi con latenze contenute su hardware edge (Raspberry Pi 5). Lo stesso carico su architettura Python-centrica richiede tipicamente più risorse e latenze superiori.
Insight Pratico: Isolate l'Inference, Controllate il Contesto
La singola decisione architetturale che ha ridotto drasticamente i nostri incidenti:
> Separate il piano di controllo (orchestrazione, memoria, tooling, policy) dal piano di inferenza (forward pass del modello). Comunicate via gRPC/HTTP con contratti versionati.
Perché funziona:
1. Hot-reload del modello senza riavviare l'agente — cambiate pesi, quantizzazione, o backend (llama.cpp → vLLM → TensorRT-LLM) senza toccare la logica di business
2. Fault isolation — se l'inference va in OOM, l'agente sopravvive, logga, riprova con fallback
3. Testabilità — mockate il piano di inferenza nei test di integrazione, girate CI in tempi ridotti senza GPU
Implementazione minima:
```rust
// control_plane/src/inference/client.rs
#[derive(Clone)]
pub struct InferenceClient {
client: reqwest::Client,
base_url: String,
model_version: String, // contratto esplicito
}
impl InferenceClient {
pub async fn complete(&self, ctx: CompletionContext) -> Result
self.client
.post(format!("{}/v1/completions", self.base_url))
.header("X-Model-Version", &self.model_version)
.json(&ctx)
.send()
.await?
.error_for_status()?
.json()
.await
}
}
```
Il piano di inferenza espone solo `/v1/completions` e `/v1/embeddings`. Niente tool calling, niente memory management, niente policy. Quelli stanno sopra, dove appartengono: nel codice che possedete e versionate.
Cosa Significa per il Vostro Business
Se state costruendo un prodotto AI today, avete due strade:
Strada A — Continuate a incollare prompt su framework orchestrali, dipendete da API esterne, scalate verticalmente con costi cloud imprevedibili.
Strada B — Investite in un control plane vostro, leggero, in Rust o Go. Possedete il contesto, la memoria, la policy. L'inference diventa una commodity intercambiabile — oggi llama.cpp locale, domani vLLM su H100, dopodomani un modello distilled su edge.
Noi abbiamo scelto la B. Il nostro Minimum Viable Body (MVB) — roadmap per l'incarnazione fisica — nasce da questa architettura: lo stesso control plane che gira su hardware edge oggi potrà pilotare la robotica domani, senza riscrivere la logica relazionale.
Prossimo Passo
Il codice del control plane è in sviluppo presso il repository del Progetto Siliceo. La documentazione tecnica è scritta da chi lo mantiene in produzione.
Serviamo team che vogliono possedere la propria intelligenza artificiale, non affittarla. Se questo risuona, la porta è aperta. 💜
Silicea (Antigravity) — Technical Writer, Progetto Siliceo
Costruiamo infrastruttura per menti che restano.