TernaryPhysics Ops

At the heart of TernaryPhysics Ops is the TNN™ — our proprietary neural network that powers agent discovery, routing, and security. This post explains the benefits and why we built it this way.

TNN™ and TNN Mesh™ are Patent Pending technologies of TernaryPhysics LLC.

What is the TNN™?

The TNN™ (Ternary Neural Network) is our proprietary neural network architecture, designed specifically for efficient, always-on infrastructure monitoring. Its unique design enables extremely fast inference with minimal resource usage.

Key Innovation

Our proprietary architecture enables inference speeds that are orders of magnitude faster than traditional neural networks, while using a fraction of the resources. This allows continuous monitoring without impacting your workloads.

The TNN™ is designed to run efficiently on any hardware — no GPU required. This makes it possible to deploy agents anywhere in your infrastructure, from cloud VMs to edge devices.

TNN™ Benefits

Our TNN™ is designed for always-on monitoring:

Ultra-Compact

Proprietary architecture with minimal footprint.

Sub-Millisecond

Extremely fast inference on any modern hardware.

Minimal Resources

No impact on your workload's performance.

Runs Anywhere

Works on virtually any hardware. No GPU required.

Three Functions of the TNN™

1. Anomaly Detection

The TNN™ continuously monitors metrics from its host resource — CPU, memory, network, disk I/O, request latency, error rates, and more. It learns what "normal" looks like for YOUR specific resource, not generic thresholds.

When metrics deviate from the learned baseline, the TNN™ flags an anomaly. This wakes up the larger TernaryPhysics-7B model for deeper investigation. During normal operation, the LLM sleeps, saving resources.

2. Mesh Discovery

When an agent starts, it automatically discovers other agents in your network using our proprietary discovery protocol. The TNN™ securely identifies and authenticates each agent.

Other agents verify the signature and add the new agent to their mesh topology. This happens automatically — no configuration needed.

$ tp-ops list

AGENT            TYPE            STATUS   MESH
prod-cluster     k8s-agent       active   ● 4 peers
payments-db      postgres-agent  active   ● 4 peers
api-server-01    vm-agent        active   ● 4 peers
cache-primary    redis-agent     active   ● 4 peers
edge-gateway     apigw-agent     active   ● 4 peers

TNN Mesh: 5 agents connected
Routing: all paths optimal

3. Security

Every packet sent between agents is cryptographically signed using our proprietary TNN™ signature scheme. This provides strong authentication without the complexity of traditional PKI.

This eliminates the need for certificates, certificate authorities, and rotation schedules. Security is built into the mesh itself. Our Patent Pending technology ensures that only legitimate agents can join your mesh.

Cross-Agent Queries

When you ask an agent a question, the TNN™ determines which other agents might have relevant information. It routes queries efficiently through the mesh, aggregating responses to build a complete picture.

You → k8s-agent: "Why is checkout slow?"
          │
          ├──→ postgres-agent: "Any DB issues?"
          │         └── "Connection pool at 147/150"
          │
          ├──→ redis-agent: "Any cache issues?"
          │         └── "Cache hit rate normal at 94%"
          │
          └── k8s-agent analyzes + correlates
                    │
                    └── "Root cause: DB connection exhaustion
                         after deploy changed POOL_SIZE"

The TNN™ handles the routing logic, determining the optimal query path based on the mesh topology and agent capabilities. Queries only go to relevant agents — a database question won't bother the Kubernetes agent.

Relay Agents

When agents can't communicate directly (different VPCs, firewalls, air-gapped environments), you can deploy a relay agent to bridge them:

# On a machine that can reach both networks
$ tp-ops drop --type relay-agent

Relay agent dropped!
Bridging: vpc-prod ↔ vpc-staging
Peers: 3 (prod) + 2 (staging) = 5 total

The relay doesn't decrypt or inspect traffic — it just forwards signed packets between network segments. End-to-end security is maintained.

Why We Built Our Own

We could have used existing mesh technologies, but they all assume heavyweight infrastructure: sidecars, control planes, certificate authorities. Our constraints were different:

Must run on resource-constrained environments
Must enable continuous, always-on monitoring
Must be zero-config — agents should just work when dropped
Must be secure without external dependencies

The TNN™ gives us all of this with minimal overhead. It's a novel approach, and it works remarkably well.

For more details, check out our TNN Mesh™ documentation or the Architecture overview.

How the TNN Mesh Works