ARCHITECTURE
The Context Layer Pipeline
At the centre sits the Harnessed Orchestrator, a domain-specific harness: the loop that takes intent from the enterprise client, reasons with the LLM, and acts through our typed context protocols on production-grade compute and storage. Everything else in the pipeline is what the harness is wired to.
THE HARNESS
Information Exchange
The Harnessed Orchestrator is the brain of the operation. It runs the loop of information exchange between humans, LLMs, and tools: it evaluates the current state, asks the LLM for the next decision, and executes it through foundational tools (bash, grep, read, write), allowing for deep manipulation of context. The LLM reasons; the harness acts.
Five things make a harness domain-specific: the tools (your operations), the policy (your manual), the checkpoints (where a human must approve), the verification (what "done and correct" means), and the trail (every run logged). The model is interchangeable; the harness is not. The same model has gone from top-30 to top-5 on agent benchmarks with only the harness changed.
Where it sits: inside accounts payable, reading incoming invoices, matching them to purchase orders, and drafting payments, with anything over a threshold paused for the owner to approve. Between intake and scheduling, qualifying a lead that arrives by web form or phone, booking the slot, and sending the confirmation. Between investigation and decision, pairing the agent that does the work with one that validates it before anything proceeds, enforced in code rather than in a prompt.
MODEL CONTEXT PROTOCOL
The Safety & Speed Boundary
The harness acts through MCP. It sends tool schemas to the LLM, and every resulting tool call goes to an MCP Server that validates and routes it; the LLM never executes code directly. MCP is the secure, structured interface that makes the harness safe to run: this strict separation guarantees that agents only access permitted data while accelerating execution via predictable JSON interfaces.
CONCRETE EXAMPLE / BETWEEN PROCESSES
Smart Logistics in Action
How a small ice cream store utilizes the Eikasia pipeline to automate stock replenishment and interactive decision-making: a domain-specific harness placed between the store floor and the supplier.
Voice Intent Captured
The store manager taps the microphone and says, "We are running low on vanilla ice cream, order 50 more tubs." The frontend transcribes this via Web MediaRecorder and sends the intent to the Harnessed Orchestrator.
Context Retrieval via A2DB
The harness hands the intent to the LLM, which realizes it needs to know the current stock to make an informed reorder. The harness executes that decision, querying the logistics ledger in Cloud Storage, and feeds the answer back into the loop: only 5 tubs left in inventory.
< on_hand: 5, status: "LOW_STOCK"
Tool Execution
With the context established, the harness dispatches the LLM's next decision as a call to the appropriate MCP tool hosted on Cloud Compute, drafting a new purchase order for the supplier. If the primary supplier's lead time has slipped, it proposes an alternative.
< status: "DRAFT_CREATED", po_id: "PO-9942"
Rich UI Generation (A2UI)
Instead of a plain text reply, the harness generates an interactive "Purchase Order Card" component and streams it back to the frontend. The manager sees the drafted order and clicks "Confirm"—the human checkpoint that closes the loop.
Policy Tuning
The manager's confirmation is logged as a successful execution trace. The Optimization layer uses this ledger history to tune the model's future behavior—applying standard control algorithms alongside Reinforcement Learning—to learn the store's exact restocking thresholds over time.
CONCRETE EXAMPLE / INSIDE A PROCESS
Accounts Payable, Systematized
The same store, two weeks later, settling the invoice for that order. This time the domain-specific harness sits inside an internal process, accounts payable, where a person used to open the email, check the spreadsheet, and log into the bank. Same loop, different tools, and a checkpoint exactly where the owner wants one.
Invoice Arrives
Two weeks later, Dairy Co. emails a PDF invoice to the store's accounts mailbox. Nobody opens it. The harness watches the inbox, picks up the attachment, and extracts the fields it needs to act: supplier, amount, purchase-order reference, due date.
< supplier: "dairy_co", amount: 1840.00, po_ref: "PO-9942", due_in: 30d
Three-Way Match via A2DB
The harness hands the invoice to the LLM, which decides it must be checked against what was ordered and what was received. The harness executes that decision, querying the purchase-order ledger and the goods-received log through A2DB. The supplier's bank details never enter the model's context; only the match result does.
< po_total: 1840.00, received: 50/50, status: "MATCHED"
Payment Drafted, Policy Applied
With the match confirmed, the harness dispatches the payment tool on Cloud Compute. The store's policy is part of the harness, not of the prompt: anything over the approval threshold is scheduled as pending and cannot be released by the model.
< status: "PENDING_APPROVAL", rule: "amount > 1000 requires owner"
Approval Checkpoint (A2UI)
The owner receives an interactive "Payment Approval" card: the invoice, the match evidence, and one action. What used to be an email, a spreadsheet, and a bank login is now a single decision with the evidence attached.
Threshold Tuning
Every approval is logged as an execution trace. Over months, the Optimization layer sees that Dairy Co. invoices matched to a purchase order are approved without edits every time, and proposes raising that supplier's auto-approve threshold. The owner decides; the harness enforces the new rule from then on.