Platform
REAP connects the information islands (devices, configurations, telemetry, topology, tickets, change history, runbooks and documentation) and reasons across them the way a senior engineer does, with every conclusion traceable to the evidence.
The loop
Four steps on top of the tools you already own; governance across all four. Agentic Network Assurance. Grounded in Evidence.
Read-only by default. Devices, configurations, telemetry, topology, tickets, change history, runbooks and documentation: the information islands, connected.
The investigation decides what evidence to gather next, gathers it and changes course when the evidence says so, the way a senior engineer works at 2 a.m. Every conclusion shows the evidence it rests on.
Recommendations, natural-language runbooks and approval-gated actions, each with a full execution record. Autonomy expands only as you approve it.
Before and after every change, a verdict with the evidence behind it; failover and recovery proven before they are needed. Restored is not the same as fixed. Before-and-after verification is a pilot deliverable today; automated verdicts are in development.
Information islands
The knowledge that explains a network is spread across ten places. REAP reads across them: device state and configuration, topology, tickets and change records, and the runbooks and design documents you give it.
Inside the platform
Six layers, external front ends on one side, the systems REAP integrates with on the other, and cross-cutting foundational services underneath.
REAP system architecture, September 2026 reference design.
Capabilities
Qualified incidents raised from REAP-collected telemetry by deterministic rules, each opened with a first analysis; posture checks flag active/standby pairs that are out of sync before the second failure. Correlation of third-party alarm streams is in development.
The cause, the affected devices and paths, and the next-best diagnostic action, with evidence links to each source; services and users where you supply the dependency context.
Pre-execution assessment against redundancy, reachability, security policy and known CVEs using state snapshots and path tracing; before-and-after comparison of configuration and state, with the evidence recorded in the change ticket (automated verdicts: in development).
Active/standby sync, running/startup drift with configuration history, and CVE (opens in a new tab) exposure prioritized by configured features and topology position; backup-path capacity as a pilot finding where interface telemetry is available.
Approved procedures compiled and validated into runbooks, each run behind an approval and recorded with the device output; tier 1 resolves the routine.
“Why is this path down”, “what changed”, “what is impacted”, “how do I safely fix this”: answered from topology, config, telemetry and history.
Where REAP runs
One platform, three places. What stays inside your boundary and what the connector cluster does are the same in all three; what differs is who operates the platform and where its data lives. Statuses as the product-status page states them.
REAP operates the platform on AWS (opens in a new tab) in U.S. regions, multi-tenant with tenant isolation enforced at the application layer, always current. For teams that want the fastest time to value and whose policy allows a managed service with read-only access.
Available Where every pilot runs today.
The same platform deployed into a dedicated VPC or VNet in your AWS (opens in a new tab), Azure (opens in a new tab) or GCP (opens in a new tab) account, using your cloud services, identity provider and PAM; your data stays in your cloud. For policies that require the platform and its data in an account you own.
By arrangement Scoped and scheduled per customer with your cloud and identity teams.
The platform on Kubernetes (opens in a new tab) on your own compute, operated by you with REAP’s support, for maximum control and data residency. For policies that exclude cloud hosting; air-gapped operation is confirmed per customer.
By arrangement Scoped per customer; the timeline agreed before a pilot is scheduled.
In all three: a connector cluster (agent plus proxy) inside your network collects telemetry natively and opens an outbound TLS tunnel, so no inbound firewall rule is needed, and the platform reaches devices only through it; read-only credentials stay in the connector, brokered through CyberArk (opens in a new tab) where you run it, never in REAP Cloud, and you can revoke them at any time. The architecture page has the detail and the diagrams; the product-status page has the statuses.
Governance
Discovery, telemetry and reasoning use least-privilege, read-only credentials, brokered through CyberArk (opens in a new tab) where available and revocable by you at any time.
Proposed changes are assessed against redundancy, reachability and security policy before approval, with the reasons shown.
Recommend by default; approved runbooks run behind a confirmation and are logged with the device output. Autonomy expands only as you approve it, action type by action type.
Read-only. REAP explains what changed, why it broke and what is affected, with the evidence attached.
Day one of every pilotREAP proposes the next best action and the runbook that would carry it out. A person decides.
Most teams live here firstREAP compares a change or a redundant pair before and after, and records the evidence in the change or incident ticket.
Pilot deliverable todayApproved runbooks run behind a confirmation, each with a full execution record.
Per workflow, per device classBounded actions run without a prompt inside limits you set: blast radius, device classes, time windows.
Earned, never assumedLevels 0 to 3 run today (Verify as a pilot deliverable); level 4 is enabled only by written agreement. Every pilot starts at Answer.
A 20-minute walk-through of an incident investigated end to end on our lab network, then a proof of value scoped to one domain of yours.