CloudCubit takes a product constraint and turns it into a running system: map the graph, write the contracts, implement the path, debug it with traces, then keep it operable.
Delivery signal
Graph
C4 · flows · contracts
Code
typed paths · tools
Debug
trace · repro · RCA
Operate
SLO · budget · loop
Solutions are delivery shapes, not a catalogue of slogans. Each track uses the same implementation loop — the graph and the runtime change, the discipline does not.
Agents · RAG · Evals
LLM applications that sit on real data paths: retrieval, tool use, guardrails, and evaluation — not a chat widget bolted onto a form.
Web · API · Mobile
Typed frontends and backends that share one contract. The UI, the API, and the mobile client consume the same domain model.
Azure · AWS · Postgres
Environments that can be rebuilt from code, with data stores chosen for the access path — transactional, cache, document, or vector.
Strangle · Integrate · Replace
Move a working system in slices. We graph the current estate, put a façade in front of the risky seams, and replace capabilities without a big-bang cutover.
Implementation is a loop, not a waterfall. The same identifiers — service names, trace ids, contract versions — travel from the first diagram through code, debug, and operations.
Phase 02
Before code, we draw the system. Domain boundaries, request paths, data ownership, and the edges that will later show up as traces.
export const graph = {
nodes: ["gateway", "intake", "agent", "rag", "ledger"],
edges: [
["client", "gateway", "https"],
["gateway", "intake", "rest"],
["intake", "agent", "command"],
["agent", "rag", "retrieve"],
["agent", "ledger", "tool:write"],
],
ownership: { ledger: "finance", rag: "knowledge" },
};System graph
Every solution starts as a directed graph: who calls whom, which store owns the write, and where the trace has to survive a hop. Code is a projection of this picture. Debug is walking it with a real request.
We implement against the diagram. Agent workflows are data — nodes, edges, tools — so a change in routing is a change you can review. Retrieval, writes, and HTTP handlers stay in modules that a trace can name.
OpenAPI, events, and tool JSON Schema exist before the handler. The UI and the agent consume the same types.
A store has a single writer. Everyone else goes through a command or a projection. That is what makes debug possible.
run_id, trace_id, and idempotency keys are arguments, not afterthoughts. If a write cannot be replayed, it does not ship.
type Tool = {
name: "ledger.apply" | "rag.search";
schema: Record<string, unknown>;
exec: (input: unknown, ctx: SpanCtx) => Promise<unknown>;
};
export function buildGraph(tools: Tool[]) {
return {
nodes: ["plan", "retrieve", "act", "commit"],
edges: [
["plan", "retrieve"],
["retrieve", "act"],
["act", "commit"],
],
tools: Object.fromEntries(tools.map((t) => [t.name, t])),
};
}
export async function invoke(run: Run, graph = buildGraph(registry)) {
const span = tracer.startSpan("agent.invoke", { runId: run.id });
const context = await graph.tools["rag.search"].exec(run.query, span);
const action = await policy.decide({ run, context });
return graph.tools["ledger.apply"].exec(action, span);
}A failing write is a span, a log line, and a missing key — not a mystery. We keep traces, structured logs, and a replayable payload so the fix is a test, not a hunch.
correlated logs
trace=8f2c1a
Trace waterfall
The error sits on ledger.apply — an idempotency key never left the agent. Fail closed, then add the key to the tool schema.
Repro → test
Capture the payload. Replay it against the failing revision. Write the assertion on the tool schema. Only then change the agent. That is the debug phase.
After go-live we do not switch to a different way of working. Telemetry writes the next graph change. The same people who drew the edges read the traces.
01
Constraint
What must never go wrong.
02
Graph
Who owns the write.
03
Code
Types that match the edges.
04
Debug
Trace the failing hop.
05
Verify
Eval, test, load.
06
Operate
Budget, then change the graph.