Answers backed by proof
When credentials and route rules allow, Woes can run a guarded live check against a real endpoint and show the status — so answers come with proof, not just prose.
Docs describe the API. They don't run it.
A developer says an endpoint returns a 401 and your docs say it shouldn't. Static context can't settle that — someone has to actually call the API. But handing production credentials to a support tool is exactly the risk teams are right to fear. Verification and safety usually pull in opposite directions.
Proof, on demand
A guarded check hits the real endpoint and returns the live status, latency, and result — evidence that a doc snippet can't provide.
Credentials stay sealed
Auth material is encrypted at rest, redacted before model calls, and never returned in plaintext. The agent uses a credential without ever seeing it.
Only where you allow it
Checks run only when credentials and route-level rules are configured. No rule, no call — verification is opt-in per route.
Answers you can verify at a glance
When a question turns on live behavior, Woes runs a guarded check with encrypted credentials and shows what actually came back. The answer stops being 'the docs say' and becomes 'here's what your API returned just now.'
Answer with the endpoint's real response
When a question turns on live behavior, Woes can execute a guarded request and show what actually came back — status code, timing, and result. The answer stops being 'the docs say' and becomes 'here's what your API returned just now.'
- Live status, latency, and result on the thread
- Verification attached to the grounded answer
- Runs only against configured, allowed routes
Verification that respects the trust boundary
A live check is never a blank cheque. It runs inside route-level controls the workspace sets, using encrypted credentials the agent can invoke but never read. If a route isn't allowed, the check simply doesn't happen — and the agent falls back to a grounded, cited answer.
- Route-level rules gate every live call
- Encrypted credentials, redacted before model calls
- Falls back to cited context when a route is off-limits
Every check is recorded and reviewable
Guarded checks leave an operator-visible record: what was called, what came back, and how it shaped the answer. Sensitive values are redacted in the trace, so you get accountability without exposing secrets.
- Operator-visible record of each guarded check
- Sensitive values redacted in the trace
- Clear link between the check and the answer
Watch a check run, top to bottom.
Add encrypted credentials and set the route-level rules that decide what may be called.
When a question needs it, Woes calls the allowed endpoint using the sealed credential.
The live status is attached to the grounded answer, with the check recorded for operators.
Guarded live API checks questions
Does Woes call my API automatically?
Only when you've configured credentials and route-level rules that allow it. If a route isn't explicitly permitted, no live call happens — the agent falls back to a grounded, cited answer.
How are the credentials protected?
Credentials are stored encrypted at rest, kept separate from source content, redacted before any model call, and never returned in plaintext. The agent can use a credential without ever seeing its value.
What does a live check actually return?
The real response status, timing, and result of the guarded request, attached to the answer as evidence and recorded in an operator-visible, redacted trace.
What if verification isn't possible for a question?
The agent answers from your grounded, cited API context instead. Live checks augment answers where they're allowed; they never replace grounding.
Back answers with live proof
Let the agent verify against a real endpoint — safely, inside the guardrails you set.