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 a deliberately tiny weight bank — 2,888 parameters total, less than 1 KB on disk — that does two things every agent needs: authenticate mesh packets and route knowledge updates between peers. It is intentionally not a general-purpose neural network. The conversational reasoning is done by TernaryPhysics-7B; the TNN handles the tiny, hot-path decisions that have to run on every packet.

Why so small

Mesh authentication and routing run on every wire packet — thousands per second per agent at scale. A 2,888-parameter model evaluates in well under a millisecond on commodity CPU. Anything bigger would push these decisions onto the slow path; anything stateful would force coordination between peers. The TNN is small on purpose.

The TNN runs in pure CPU on any hardware — no GPU, no SIMD requirement, no special instructions. This is why agents can drop onto edge devices, low-spec VMs, and embedded boxes without changing the deployment.

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