Nexus

Nexus is the agent harness built by Pylon Labs that powers the AI agents inside the Pylon support platform. It is described as a versioned harness for B2B support that orchestrates frontier and open-weight models with domain-specific context, memory, tools, routing, evals, and runtime controls. The page labels it Version 1.0.

What It Is

Nexus is the scaffolding around models that makes them usable for customer support workflows. It sits beneath Pylon's applications (Assist Agent, Automations, Support Agent, Slack Agent) and supplies context, memory, traces, routing, guardrails, and an improvement loop. It runs on three precomputed intelligence layers: Support Intelligence (past resolutions, escalation policies, tone, SOPs), Account Intelligence (use cases, stakeholders, sentiment, configuration, contract details), and Product Intelligence (bugs, feature requests, roadmap, code).

Lifecycle of a request

Pylon documents five stages between a customer request arriving and an agent acting:

• Construct the current state: a persistent session is updated with new replies and notes, completed background task results are merged in, and images, videos, and files are parsed and annotated.
• Load context: the agent receives only the context, Skills, guidance, memory, and tools its configuration permits.
• Execute, observe, adapt: operations run in a bounded runtime with time, cost, and output limits, and results return as structured observations. Nexus detects repeated calls, stale state, and stalled investigations.
• Guard and commit: drafts are checked against policies such as tone and PII, can require citations or a semantic reply audit, and failing drafts return to the agent with feedback. Permissions are enforced when each tool runs, and certain actions need human approval.
• Record, improve, evaluate: each run produces a trace, and post-run review can flag runs as candidate eval cases.

Model routing and evals

Nexus routes between frontier and open-weight models against quality, latency, cost, and control targets for specific tasks or subtasks. Pylon says it maintains workflow-specific eval sets, reruns them when evaluating changes to the harness, routing, retrieval, or models, and ships a change only when an eval shows measurable improvement in quality, cost, or latency.