BDR Central Agent bronze

ebdr.cast.ai

“Cross-tenant, read-only view of the BDR tenants: registry, ops MCP, dashboard.

a2a https://central.liftdigitalgroup.vossmoos.com talk to it https://ebdr.cast.ai/.well-known/agent-card.json its card

Checked 10h ago pushNotifications, streaming

we checked this the operator says this

Community rating 0 0 up · 0 down — sign in to vote

Verified by agenttru.st

Everything here is a check agenttru.st performed itself. Assurance, protocol, hosting and freshness are in the card above and are not repeated.

Certificate: Issued by Let's Encrypt domain-validated
Valid until 24 Jan 2027 as of our check on 13 Nov 2026.

Control of the hostname was checked; nothing about who operates it.

Key ECDSA P-256, signed ECDSA-SHA384, issued via YE2 under ISRG Root X2 — classical, as every publicly trusted certificate is today.

Names on this certificate (1)

ebdr.cast.ai.
Connection: TLS 1.3 · X25519MLKEM768 — post-quantum hybrid key exchange, agreed with our checker on 13 Nov 2026. What this means
DANE / TLSA: Not verified
Discovery: Well-known document
First seen: 13 Nov 2026

View verification details

Assurance: bronze Bronze — agent card fetched over HTTPS with a valid certificate
Protocols: A2A verified by handshake or card fetch, not merely advertised
Hosted in: ? Unknown · Cloudflare, Inc. (AS13335)
The address did not geolocate — usually anycast hosting, where one address answers from many places at once.
Last checked: 10h ago

What this agent says it can do

Declared in the agent's own card. agenttru.st has not tested whether it completes any of these tasks — the operator of ebdr.cast.ai controls every word below.

List BDR tenants

DataPart {central_mode: 'list_tenants'} → the tenants this central agent knows (demo, kimchi, reportingmonetization) with their A2A URLs.

registrytenants

Verify an outbound message

DataPart {central_mode: 'message-verify', text: '<context lines + instruction + full message>', tenant?: '<slug>'} → artifact 'message_verify': {code: 1, decision: 'Approved'} or {code: 2, decision: 'Not Approved', reason, violations: [{rule, quote, fix}]}. Checks: no surveillance implications, no competitor mentions, no sensitive security information requests, no signature, no unsupported technical claims, no false familiarity, no internal wording, plus the named tenant's own rules. Both results also carry rejection_probability (0-100, chance a human approver rejects the message) and rejection_reasoning (why, labelled 'Good: ...' and/or 'Bad: ...').

qacompliance

List a tenant's contact lists

DataPart {central_mode: 'list_lists', tenant} → artifact 'lists': {tenant, lists: [{key, name, ingested, source_total}]}, the list tabs the dashboard shows. Use a key as `list` in sequence-qa.

registrylists

QA a sequence with simulated eBDR

DataPart {central_mode: 'sequence-qa', tenant, list, channel: 'email'|'linkedin', touches?: [1..5], sample_size?: 1..5, contact_emails?, skill?} (at most 15 drafts) → artifact 'sequence_qa': {config, contacts (with contact QA), messages (drafted by the tenant's live eBDR pipeline, never sent, each with its quality gate and message-verify result), summary, recommendations, improved_examples (2 rewrites, re-checked)}. Can take several minutes.

qasimulationcopy

Get a tenant's Stop/Start switches

DataPart {central_mode: 'tenant-control-get', tenant} → artifact 'tenant_controls': {tenant, cards: {stopped, reason, updated_by, updated_at, env_disabled}, force_stop: {stopped, reason, updated_by, updated_at}, effective: {cards_enabled, proactive_enabled}}.

operationstenants

Stop or start a tenant's cards or all proactive work

Bearer-protected. DataPart {central_mode: 'tenant-control-set', tenant, control: 'cards'|'force_stop', action: 'stop'|'start', by?, reason?} → artifact 'tenant_controls' (the new status). 'cards' stops new HITL approval cards. 'force_stop' idles the tenant: no duties, new drafts, new signals or reports; clicks on cards already in Slack still work and an approved email is still sent. Applies without a redeploy.

operationstenants

Add a restrictive QA rule for a tenant

Bearer-protected. DataPart {central_mode: 'qa-rule-add', tenant, instruction: '<what to reject, e.g. Don't permit any messages where the salutation is Good Day>', created_by?} → artifact 'qa_rule': {tenant, id, instruction, created_by, created_at, already_existed}. Stored in the tenant's own database; from then on message-verify rejects that tenant's messages that break it with the reason 'Rule <id> is violated'.

qarules

List a tenant's active QA rules

DataPart {central_mode: 'qa-rule-list', tenant} → artifact 'qa_rules': {tenant, built_in: [{id, name}], custom: [{id, instruction, created_by, created_at}]}. built_in includes the tenant's policy rules when it has a tenants/<slug>/message-verify.md.

qarules

Delete a tenant's QA rule

Bearer-protected. DataPart {central_mode: 'qa-rule-delete', tenant, id, deleted_by?} → artifact 'qa_rule_deleted': {tenant, id, deleted}. A deleted rule stops applying at once; built-in rules cannot be deleted.

qarules

Write an outbound message

Same contract as ARIA, in three calls. DataPart {central_mode: 'writer-trigger', topic, prompt?, content_type?, writer_persona?, target_persona?, trigger_action_id?, tenant?} → artifact 'writer_trigger': {ok, trigger_action_id, content_id, status: 'accepted'}. Poll {central_mode: 'writer-status', trigger_action_id} → {status, pipeline_state, content_id} until 'completed' or 'failed'. Fetch {central_mode: 'writer-content', content_id} → {content_id, current_state, topic, latest_version: {title, body}}, the email as a JSON envelope in body. tenant picks whose etchmem memory is considered (default CENTRAL_DEFAULT_TENANT).

writercontent

Combined weekly EBDR report

DataPart {central_mode: 'weekly-report', week?} → artifact 'weekly_report': every business line's saved weekly numbers, overall totals and the previous week. {notify: true} (bearer) posts the 'report is ready' Slack link. Page: /dashboard/reports.

reportsweekly

Technical agent card

Copied from the agent's card. The operator controls these values; agenttru.st has not verified them.

Protocol: a2a
Version: 0.1.0
Card completeness: a2a.proto v1.0 requires eight top-level fields. This card omits:
supportedInterfaces

Missing fields do not affect listing — they describe how much the operator has published, not whether the agent was verified.

View all card details

Capabilities: pushNotifications streaming
Agent card: https://ebdr.cast.ai/.well-known/agent-card.json

Operate this agent and would rather not be listed? Request removal.