Nexus is the agentic harness that powers capabilities in Pylon. It runs on three layers of precomputed context: your support history, account context, and product knowledge. It provides the scaffolding around models that makes them useful for real customer workflows.
This is what happens between a customer request arriving and an agent taking its next action. We’ll follow one request through five stages. In this example, a customer reports a CRM sync error.
Nexus reconstructs the session so the model sees only what is new since it last acted, including results from background tasks that completed in the meantime.
A customer sends a video of a CRM sync error and then follows up with another message. Nexus transcribes the video, adds the new message to the session, and incorporates the result of a background task that already classified the issue as a CRM integration problem.
Nexus equips the agent with the knowledge, Skills, guidance, and tools it needs for the request, based on what the agent is allowed to access and do.
Nexus retrieves Account Intelligence about the customer’s CRM use case and sync requirements from Customer Success and Sales calls; Product Intelligence from Salesforce docs and open Salesforce feature requests; and Support Intelligence from similar prior investigations and any active incident affecting the integration.
Nexus executes each approved operation inside a bounded runtime, then routes the result to the appropriate model as a structured observation for the next step.
The agent searches the logs for the underlying error, looks up the error in Salesforce docs, and compares its findings with the codebase and product roadmap. It concludes that the customer’s field type is not supported for sync.
Nexus reviews outputs against defined policies, such as tone and PII requirements. Based on approved controls, Nexus takes action or suggests an action with cited findings.
Nexus verifies that the draft does not include PII, uses the correct sender identity, and includes supporting citations. The explanation is ready to send. Filing a feature request pauses for human approval.
Every execution produces a trace of what the agent searched, which tools it used, what failed, and how the run ended.
Nexus stores the trace. The finding about supported CRM field types surfaces a documentation update, and the approved feature request is associated with the customer account.
Nexus uses both frontier and open-weight models, routing them against quality, latency, cost, and control targets for specific tasks or subtasks.
Pylon evaluates new models and techniques against workflow-specific eval sets. Nexus changes routing only when testing shows a measurable improvement in quality, cost, or latency for the relevant work.
No. Context and tool exposure are scoped by the agent’s configuration for the task at hand. Every tool call runs with defined permissions and system-level guardrails. Sensitive or consequential actions can require human approval.
A model alone does not know what context matters for a specific customer, what has changed since its last run, which data and actions it may access, or how to improve from prior outcomes.
As models become more capable, the harness around them determines how that intelligence is applied to a specific domain and workflow.
Nexus provides that operational layer: enterprise context, model routing, controlled execution, permissions, traces, and evals.
