JITNA Protocol
"The HTTP of Agentic AI"
Just In Time Nodal Assembly — the open communication protocol that defines how AI agents discover, negotiate, and execute work together — assembled just in time, dissolved when done.
What is JITNA?
JITNA (Just In Time Nodal Assembly) is an open communication protocol defining how AI agents discover each other, negotiate tasks, execute work, and verify results — without any permanent agent hierarchy or pre-configured workflows.
Inspired by HTTP in web engineering — HTTP defines how clients communicate with servers in a stateless way. Similarly, JITNA defines how AI agents communicate and coordinate in a stateless way. Agents are assembled into working groups just in time based on the intent of the current task, then dissolved when it completes.
JITNA is not a single file or class — it is a three-layer system where each layer has a distinct role: Protocol (wire format), Language (6-field schema), and Intake (user-facing).
Three-Layer Architecture
JITNA is divided into 3 distinct layers — each with its own responsibility and implementation file.
The JITNAPacket — header + intent + payload + validation. Secured by Ed25519 signatures (RFC 8032) and governed by The 9 Codex safety rules.
rct_control_plane/jitna_protocol.pyThe I / D / Δ / A / R / M schema — used for prompts, memory tagging, vault metadata, and DelentiaDB commits. 50+ workflow templates available.
50+ workflow templatesThe user-facing JITNAPacket — takes a plain intent string + context dict, computes content hash for replay integrity, and dispatches to the engine.
microservices/intent-loop/loop_engine.py6 JITNA Language Fields
The canonical 6-field schema for structuring any intent — used in prompts, memory tagging, vault metadata, and DelentiaDB commits.
The primary objective — what the agent ultimately wants to achieve. Structured as an IntentObject with goal, constraints, and priority.
Facts and context currently available — retrieved from DelentiaDB, external APIs, or context window. What the system actually knows right now.
The gap or desired change between current state and goal (Δ = I − D). Drives agent assembly — large delta signals need for specialist agents.
The algorithm or strategy to apply — chosen by the assembled agents to close the delta. Documented in the JITNA packet for full auditability.
Lessons learned, feedback, or post-execution review — SignedAI consensus scores across 8 dimensions. Informs whether the approach succeeded.
Long-term context persisted across sessions — routing history, outcome quality, and learned patterns stored in DelentiaDB 7D. What enables continuous self-improvement.
JITNA Language: Δ = I − D → select A → Execute → R → update M
The Negotiation Pattern
JITNA agents do not blindly execute — they negotiate. Agents can counter-propose and refuse tasks outside their domain.
JITNA vs Tool-Calling APIs
| Dimension | Tool-Calling APIs | JITNA Protocol |
|---|---|---|
| Communication model | Request → Response | PROPOSE → COUNTER → ACCEPT/REJECT |
| Agent autonomy | None (tools are passive) | Full (agents can negotiate and refuse) |
| Verification | None built-in | Ed25519 signed packets |
| Replay support | Not supported | SHA-256 checkpoint chain |
| Multi-agent consensus | Not supported | SignedAI integration (Tier S/4/6/8) |
| Discovery | Hardcoded list | Dynamic registry with capability matching |
| Standardization | Vendor-specific | Open RFC (Apache 2.0) |
RFC-001 is the open specification defining: JITNAPacket structure, message types (PROPOSE/COUNTER/ACCEPT/REJECT/COMPLETE), Ed25519 security mechanism, The 9 Codex rules, and Adapter Interface requirements for integration with other systems.