Clanker Cloud Explained: How Prompts Become Cloud Evidence
See how Clanker Cloud cleans a request, chooses a provider, resolves credentials, runs parallel probes and keeps usable evidence when one probe fails.
The whole story in 6 lines
Clanker cleans the question, selects a route and identity, gathers bounded evidence, and preserves failures beside usable results.
- Routing uses the newest explicit user turn instead of stale transcript or appended context.
- Keywords choose clear provider routes while an LLM resolves ambiguity and falls back safely on failure.
- Backend API keys and URLs follow explicit precedence rules before any remote request begins.
- Provider credentials create a client at one boundary, with a documented local fallback when remote hydration misses.
- Decision rules map a question to registered operations and schedule only dependency-ready workers.
- Parallel results keep original order, merge successful evidence, and report failures as metadata.
The confident answer with the wrong account
A cloud assistant gives a polished diagnosis, but it inspected the wrong provider and account. Fluent wording cannot repair evidence gathered from the wrong place.
Four ideas keep this path honest. A route selects the service, a backend stores account data, a credential proves identity, and a probe gathers one fact.
We will follow one checkout error question through six boundaries. The verified path comes from the local Clanker repository, while unavailable hosted internals stay outside our claims.
Each boundary produces one inspectable artifact for the next stage. Now let us start with the text that routing is actually allowed to read.
Keep only the request that should route
The verified CLI can receive a whole chat transcript from Clanker Cloud. Earlier questions, assistant replies, and cached context all arrive in one text block. That bundle is useful for conversation, but it is noisy for routing.
The cleanup function searches backward for the last explicit You marker. That choice prevents an older request from steering a new provider decision. It also keeps the extraction rule deterministic and easy to test.
The newest question is followed by a Current AWS context section. Cached details may describe yesterday rather than the user's present goal. Which text should cross into the routing function?
The transcript collapses into one clean question. The next stage receives the checkout error request without the earlier deploy conversation or cached context. This output is smaller, but more importantly, it matches the latest intent.
Prompt cleanup narrows the routing input, but it does not rewrite the user intent. The original question still remains available for later evidence and synthesis. Next, we will see how that focused question selects a provider path.
Use cheap signals before an LLM tiebreaker
Now that the question is clean, routing begins with deterministic keyword families. Provider names and distinctive services light only the relevant flags in a ServiceContext. This cheap pass does not need a model call.
A clear AWS phrase can stay on the cheap path. If nothing matches, the current implementation defaults to AWS and GitHub context instead of inventing a new provider. That fallback is explicit in the code.
Some phrases trigger more than one service flag, which makes the cheap result ambiguous. A wrong winner could send later calls toward the wrong account system. Should the first keyword simply win?
The LLM classifier returns one named service when ambiguity needs a tiebreaker. Its response is cleaned and parsed as JSON before changing the route. If either step fails, Clanker keeps the earlier keyword result.
Routing is a guarded decision rather than an unlimited model guess. Our checkout question resolves to AWS, so unrelated provider clients remain unopened. Next, that route needs a backend target and API key.
Resolve the backend before sending secrets
The AWS route first checks whether a Clanker backend is configured. API keys follow a strict order: explicit flag, configuration value, then environment variable. An empty value falls through without becoming a fake credential.
The backend address has its own precedence ladder. A configured URL wins, then an environment URL, then a named environment, and finally the testing default. Unknown names also fall back to testing.
URL selection and API-key selection are separate decisions. Keeping them separate makes it possible to inspect exactly which endpoint receives which account token. That separation also makes precedence bugs easier to isolate.
Only after both values resolve does the client form an authenticated request. The API key travels in the X-API-Key header toward one explicit backend endpoint. The HTTP client also enforces a thirty second timeout.
Backend resolution creates a precise remote boundary before provider secrets are requested. The endpoint and authentication source can both appear in debug evidence without printing the secret. Next, we will follow the credential response into an AWS client.
Turn one credential source into one client
With the backend boundary fixed, Clanker requests only the credential type required by the route. The AWS path calls the provider-specific credentials endpoint. Other providers use their own typed endpoints and clients.
The response contains credential fields that are passed into the AWS client constructor. The explainer represents them as a sealed token because their values should never become narration. Only their source and destination matter here.
The backend can be missing, unauthorized, unavailable, or lack that credential. Those failures are different, but none creates a usable remote client. Does the entire investigation stop at this boundary?
A backend hit or a local profile creates exactly one AWS client for the next phase. That client carries the chosen account identity into every evidence call. Client creation errors still stop the branch rather than hiding a broken identity.
Credential hydration ends at the provider client boundary, not inside the final answer. Later stages consume capabilities from that client without displaying secret fields. Next, Clanker will decide which bounded probes that client may execute.
Map intent to dependency-aware probes
The provider client is ready, so the agent analyzes the question and traverses a decision tree. Matching nodes name registered worker types instead of arbitrary commands. Higher priority matches replace lower priority duplicates for the same worker.
Each worker type maps to a fixed operation generator. Logs, metrics, infrastructure, security, and cost agents receive only the operations defined for their role. Unknown worker names receive no improvised operation list.
A security worker needs logs and service configuration, but neither result exists yet. Starting early would make its conclusions depend on missing inputs. Should it launch beside the first probes?
The scheduler forms ordered groups. Independent log and metrics work can share the first wave, while later workers wait for their promised inputs. Every group completes before the coordinator advances to the next order.
Planning converts a broad question into a bounded, dependency-aware execution plan. The plan carries worker names, mapped operations, and dependency order. Next, those ready probes will run together and return evidence with explicit failures.
Keep partial evidence and name every failure
★ If you remember one thing · A failed probe stays explicit while successful evidence remains usable.
The plan now fans ready workers out within each order group. A separate AWS helper can also run mapped operations concurrently while preserving their original result order.
Each probe returns a result shard tagged with its operation and original index. Successful shards carry facts, while failed shards carry an error instead of invented data.
The metrics probe fails while logs and infrastructure complete. Will aggregation discard the two successful findings?
Two successful shards enter the aggregated result, while the failed shard remains outside the evidence payload. Metadata records the total, completed, and failed counts.
Switch the Probe health control through both choices. Compare the complete evidence set with the partial result that keeps facts and names the missing probe.
The verified code proceeds with available data after some timeouts and nonfatal failures. Final synthesis can explain uncertainty, but the hosted app implementation is not present here. Now let us step back and see the whole picture together.
One traceable chain from question to evidence
We started by isolating the newest explicit user turn. That protects routing from stale conversation and appended context.
Then we used keyword signals for clear routes and an LLM only as a guarded tiebreaker. Keyword inference remains available when classification fails.
Next, separate precedence rules selected the backend address and API key. That made the remote authentication boundary inspectable before provider credentials moved.
Credential hydration created one provider client from a backend response or documented local fallback. The chosen identity then followed every evidence call.
The decision tree and operation catalog bounded the investigation. Dependency groups prevented later workers from running before their required facts existed.
Parallel execution shortened independent work, while aggregation kept successful facts and counted failures. This is the key reliability boundary for partial evidence.
Together, these boundaries turn an open cloud question into a traceable evidence packet. The worked branch order comes from the local Clanker source, while hosted internals remain unclaimed.
The whole story in 6 lines
Clanker cleans the question, selects a route and identity, gathers bounded evidence, and preserves failures beside usable results.
- Routing uses the newest explicit user turn instead of stale transcript or appended context.
- Keywords choose clear provider routes while an LLM resolves ambiguity and falls back safely on failure.
- Backend API keys and URLs follow explicit precedence rules before any remote request begins.
- Provider credentials create a client at one boundary, with a documented local fallback when remote hydration misses.
- Decision rules map a question to registered operations and schedule only dependency-ready workers.
- Parallel results keep original order, merge successful evidence, and report failures as metadata.