DocsTNN Mesh

TNN Mesh

How agents discover each other and form a self-organizing mesh network.

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

Overview

When you drop multiple agents, they automatically discover each other and form a mesh network. This mesh enables cross-resource investigation — when you ask one agent a question, it can query other agents to trace causality across your entire infrastructure.

The mesh is powered by the TNN™ (Ternary Neural Network), our proprietary ultra-compact model that runs on every agent. The TNN™ handles three critical functions: discovery, routing, and security.

The TNN™

Ultra-Compact

Proprietary architecture. Runs anywhere.

Sub-Millisecond

Extremely fast inference. No GPU needed.

Secure by Design

Novel signature scheme. Zero-config security.

The TNN™ uses a proprietary architecture optimized for efficiency, enabling always-on monitoring without impacting your workloads.

Discovery

When an agent starts, the TNN™ automatically discovers other agents in your network. The mesh topology is built automatically — no configuration required.

Mesh status
$ 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

Discovery mechanisms:

  • • Auto-discovery — Same network segment
  • • Kubernetes-native — Within K8s clusters
  • • Static peers — Cross-network configuration

Network Requirements

Agents require minimal network configuration for mesh communication. Specific port requirements are provided during installation.

  • All mesh traffic stays within your network
  • No data is sent to external servers
  • Encrypted agent-to-agent communication

Relay Agents

When agents can't communicate directly (different VPCs, network segments, or firewalls), you can deploy a relay agent to bridge them:

Relay deployment
# 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

When to use relays

Deploy relay agents when you have agents in isolated network segments that need to share context during investigations. Common scenarios: multi-VPC deployments, hybrid cloud, air-gapped environments with controlled bridges.

Cross-Agent Queries

When you ask an agent a question, it may query other agents in the mesh to build a complete picture. Here's what happens:

Cross-agent investigation
$ tp-ops ask prod-cluster "Why is checkout slow?"

Investigating across mesh...

→ k8s-agent (prod-cluster): payment-api latency 3x normal
  └─ Querying postgres-agent...

→ postgres-agent (payments-db): Connection pool at 147/150
  └─ Querying k8s-agent for recent deploys...

→ k8s-agent: Deploy 2 hours ago changed POOL_SIZE env var

Root cause: Deploy removed POOL_SIZE config, defaulting to 150.
Connection pool exhausted under normal load.

Fix: Restore POOL_SIZE=50 in payment-api deployment.
Apply fix? [yes/no]

Cross-agent queries only happen during active human sessions. Agents don't autonomously communicate without your involvement.

Mesh 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.

Zero-config security

No certificates to manage, rotate, or revoke. Security is built into the mesh.

Network-local only

Mesh traffic never leaves your network. No cloud relay, no external dependencies.

TNN Mesh™ security technology is Patent Pending.

CLI ReferenceArchitecture