mklang platform

Workflow con IA · Progettazione e piattaforma gestita

Progettiamo workflow con IA.
Gestiamo la piattaforma su cui girano.

mklang descrive in un documento come l’IA lavora: cosa deve produrre, quali condizioni deve soddisfare e quando correggere, chiedere una decisione o fermarsi.

mklang platform collega questo lavoro ai sistemi aziendali e gestisce l’esecuzione del workflow, le credenziali e le azioni esterne.

Partiamo dal tuo processo, nuovo o già automatizzato. Realizziamo il workflow e lo mettiamo in funzione sulla piattaforma gestita.

01 / Processo

Cosa richiede ancora il tuo intervento?

01

Ricostruire cosa è successo

Un’esecuzione si ferma e devi capire quali passaggi sono già stati completati.

02

Rincorrere una decisione

Serve una persona, ma la richiesta e la risposta passano fuori dal flusso.

03

Verificare prima di riprovare

Il sistema esterno potrebbe aver già eseguito l’azione, anche se non hai ricevuto una risposta.

Questi passaggi fanno parte del processo da progettare.

02 / Console operativa

Il tuo team vede dove intervenire.

Dalla console gli operatori consultano le esecuzioni, rispondono alle decisioni in attesa e verificano gli eventi registrati. Le decisioni operative restano alle persone che conoscono il processo.

Sequenza illustrata del percorso operatore, costruita con schermate dell’interfaccia reale e dati dimostrativi. Non è una registrazione continua di un’esecuzione. Il filmato usa la console reale con dati fixture. Il poster illustra il confine tra macchina e workflow. Scarica il video (WebM)
Leggi la trascrizione del filmato (20 secondi)
  1. 0–4s: La piattaforma carica richiesta e fatti disponibili. La macchina mklang prepara una risposta; uno step successivo esegue l’azione esterna.
  2. 4–10s: Un estratto esatto di support_reply.mkl mostra accettazione, al massimo due correzioni o escalation. I gate in prosa sono giudizi del modello; l’host applica le transizioni.
  3. 10–16s: Ritagli del pannello reale mostrano domanda, contesto e controlli di risposta. L’esempio chiede cosa debba dire la risposta, con eventuali fatti mancanti o istruzioni. La console è in inglese.
  4. 16–20s: Applicare la risposta permette alla macchina di usare l’istruzione. Il workflow può proseguire: non significa che il run sia concluso o il messaggio inviato. La console reale mostra In progress.

La macchina completa è disponibile qui sotto. È una sequenza illustrata con snapshot fixture di sola lettura, non una registrazione continua di un’esecuzione.

Una macchina mklang dentro il workflow

  1. Piattaforma · Acquisizione

    Recupera gli input.

    Un connettore legge la richiesta e le informazioni disponibili nei sistemi aziendali.

  2. mklang · support_reply.mkl

    Prepara e valuta la risposta.

    Lo stato draft genera una bozza. I gate decidono se restituirla, correggerla fino a due volte o chiedere una persona.

    Con escalate l’host sospende l’esecuzione. Dopo la risposta umana, apply_human_decision prepara il risultato.

  3. Piattaforma · Azione esterna

    Applica il risultato.

    Un successivo step del workflow può inviare la risposta tramite connettore, secondo autorizzazioni e controlli della piattaforma. La macchina non invia messaggi.

La macchina seguente è completa e verificata con l’interprete usato dalla piattaforma. Acquisizione e invio sono un esempio di integrazione, non inclusi nel file. Nessun dato cliente.

Il diagramma mostra due stati della stessa macchina: un singolo step mklang del workflow può contenere più stati, valutazioni e correzioni.

Leggi il documento mklang completo
# Platform example: prepares text; never sends a message (ADRs 0001 and 0040).
# Prose gates are model judgements, not guarantees of factual correctness.
# The mkp: hooks below are supplied by mklang platform, not standalone mklang.
mklang: "0.4"
machine: support_reply
entry: draft
budget: 6
default_tier: balanced
result: reply

context:
  request: ""
  facts: ""

hooks:
  - name: "mkp:eq:output:"
    description: True when the generated text is the empty string.
  - name: mkp:has:output
    description: Checks presence only, not correctness or quality.

states:
  draft:
    structure: A short support reply, using only the supplied facts.
    execution: Do not invent facts or claim to have performed any external action.
    prompt: |
      Request: {{request}}
      Available facts: {{facts}}
      Draft a reply. If facts are missing, say what needs clarification.
    output: reply
    gates:
      - when: the draft is empty
        hook: "mkp:eq:output:"
        fail: true
      - when: the reply answers the request and is supported by the supplied facts
        then: ok
        to: END
      - when: the draft can be corrected using only the supplied facts
        repair: 2
        to: draft
      - when: otherwise
        escalate: true
        ask: "What should the reply say? Supply the missing facts or an instruction."
        to: apply_human_decision

  apply_human_decision:
    structure: A support reply following the human instruction.
    execution: Do not claim to have sent a message or performed any external action.
    prompt: |
      Request: {{request}}
      Available facts: {{facts}}
      Previous draft: {{reply}}
      Human instruction: {{human.reply}}
      Prepare the reply using these instructions.
    output: reply
    gates:
      - when: a reply was produced
        hook: mkp:has:output
        then: ok
        to: END
      - when: otherwise
        fail: true
Scarica support_reply.mkl ↓

I gate in linguaggio naturale sono valutazioni del modello. I test simulano le sue risposte per verificare i percorsi, non ne misurano l’accuratezza. Il controllo mkp:has:output verifica soltanto che un valore sia presente e non vuoto, non che sia corretto. Il controllo sull’output vuoto arresta la bozza prima della valutazione dei gate in prosa.

Il linguaggio autonomo può usare stati tool: forniti dall’host. Nelle macchine della piattaforma sono vietati: l’I/O appartiene agli step espliciti del workflow. I gate mkp: di questo esempio sono forniti dalla piattaforma; il file non è un esempio di esecuzione autonoma senza quell’host.

03 / Offerta

Realizzazione iniziale e piattaforma continuativa.

01 / Progetto iniziale

Il progetto.

Esaminiamo il flusso attuale, definiamo il comportamento atteso, realizziamo i collegamenti e verifichiamo il processo prima dell’avvio.

02 / Canone ricorrente

La piattaforma.

Il processo viene eseguito sul runtime ospitato di mklang platform, con console operativa, credenziali gestite e registrazione degli eventi.

03 / Responsabilità operative

Il tuo team.

Mantiene le regole di business e prende le decisioni umane previste dal flusso.

Progetto e canone ricorrente sono definiti su preventivo. Modifiche successive e condizioni di assistenza vengono concordate nel perimetro dell’incarico.

Il consumo dei modelli è fatturato dal relativo fornitore al cliente.

Definiamo la realizzazione di un processo concordato, nuovo o già automatizzato. L’offerta non comprende l’assistenza generica su automazioni esistenti o la loro importazione automatica.

04 / Errori e recupero

Un esito incerto richiede una verifica.

Se l’esito di un’azione non può essere stabilito in sicurezza, l’esecuzione si ferma. Il recupero tramite una nuova chiamata dipende dalle garanzie di deduplicazione del sistema esterno. Verificare l’esito presso il fornitore richiede il supporto del connettore.

Controlli, gestione dei dati e limiti →

Un processo definito non garantisce la correttezza di ogni valutazione dell’IA. Le condizioni valutate dal modello vanno verificate sui tuoi casi; le regole esatte richiedono controlli deterministici.

Riepilogo dei tre test di crash

Riepilogo editoriale dei casi verificati dalla suite, non output letterale del comando pytest. Questi test verificano il recupero della piattaforma; non misurano la correttezza delle valutazioni dell’IA.

La suite interrompe il processo dopo che il fornitore ha registrato l’azione e prima che arrivi la risposta. Verifica separatamente quando fermarsi, quando una nuova chiamata è sicura e quando verificare l’esito presso il fornitore.

Con deduplicazione dichiarata dal connettore, la chiamata può essere ripetuta con la stessa chiave: due richieste, una sola azione.

Con una verifica dell’esito supportata dal connettore, il recupero può confermare l’azione presso il fornitore e proseguire senza ripetere la scrittura.

$ uv run --directory tests/e2e pytest -k 'crash or deduplicates'

crash       vendor records action; reply never arrives

no guarantee    ambiguous claim → run stops, no second call
deduplication   same key → two calls, one action
reconciliation  vendor confirms action → no second write

PASSED      no duplicate effect in each tested recovery path

Il test di crash viene eseguito a ogni modifica. Il test è nel repository privato della piattaforma.

05 / Primo contatto

Mostraci il punto in cui devi intervenire.

Descrivi il processo, gli strumenti coinvolti e i passaggi che richiedono valutazioni o interventi umani. Esamineremo se è adatto alla piattaforma e quale lavoro serve per realizzarlo o ricostruirlo.

Onboarding gestito disponibile, un workflow alla volta.

  • Processo attuale o da realizzare
  • Strumenti coinvolti
  • Intervento ricorrente
  • Volume indicativo
Descrivi il workflow ↗info@gianlucamazza.it