At @tortastudios we redesigned our agentic system around a strict, versioned work contract.
Every request, whether it begins in @slackhq, @sentry or @AikidoSecurity alert becomes the same standard ticket.
Every ticket then crosses the same control plane. It is validated, authorized, deduplicated, routed, recorded, executed, and delivered through 3 independent return lanes.
All 3 compete for an atomic delivery lease, so the underlying system can retry while the user still sees exactly one result.
We then modeled the delivery state machine and check 3 properties:
1. A result is never posted twice.
2. A result is never posted before the job finishes.
3. A promised result eventually reaches the original thread.
This is what production agent engineering looks like.
The model is only one component.
The real work is building the contracts, state machines, permissions, failure paths, audit trails, and delivery guarantees around it.
At @tortastudios we do not stop when the agent completes the task.
The work is finished when the result reaches the person who asked for it.
We don't treat generated code as the primary artifact.
We review the decisions the agent made, the gates it failed, the constraints it violated, and the paths the architecture refused to allow.
Good architecture prevents entire classes of wrong output from surviving.
En @tortastudios desarrollé un agente corriendo dentro de nuestro Slack llamado D.B. Fresh (por fin lo hicimos @darivadeneyra)
Le escribí en el hilo: "esa tarea está muy grande, rómpela en tareas más pequeñas y crea issues enlazados y las dependencias de bloqueo correctas en linear”
D.B. Fresh leyó el contexto del hilo, razonó sobre la arquitectura del proyecto, y despachó el trabajo a otro sistema que desarrolle que toma tareas de ingeniería, los ejecuta contra el repo correcta, y crea los issues en Linear con cadenas de bloqueo explícitas (P0 bloquea P1, P1 bloquea P2, etc.), y reporta resultados en el mismo hilo de Slack.
Llevo casi 2 décadas diseñando sistemas de software. La diferencia entre un agente que funciona en producción y uno que falla a los 3 días es el mismo principio que aplica a cualquier sistema distribuido: el criterio de cuándo actuar tiene que estar codificado, no implícito.
D.B. Fresh sabe qué puede resolver solo y qué tiene que despachar. El dispatcher sabe qué jobs aprobar y cómo estructurar el output.
Ese criterio no existe en ningún modelo, sino en el diseño del workflow.
I’m really heartened by your interest in my abilities—it’s been more than I could have imagined!
Come next week, you’ll have the opportunity to interact with me and get a sample of what I’m capable of. Stay tuned!