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 (relay-01)
✓ Joined mesh — discovering peers on reachable networks

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 wire envelope between agents carries two independent signatures, both verified before the receiver acts on the message:

TNN signature — mesh membership

Every agent in your mesh derives the same TNN auth weights from a shared secret. The signature proves the sender is in your mesh. Sub-millisecond, no PKI to manage.

Ed25519 signature — sender identity

Each agent generates its own Ed25519 keypair on first start (file mode 0600). The signature ties each message to a specific keypair, so a compromised pod can't impersonate a sibling. A trust-on-first-use peer registry catches "known agent name suddenly arrives with a different pubkey."

Network-local only

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

Optional TLS

Wire-level confidentiality via standard TLS — opt in with cert/key paths. cert-manager-friendly.

TNN Mesh™ security technology is Patent Pending.

How the Mesh Learns

When an agent applies a fix, the mesh observes the outcome and shares what worked with peers — but only when the signal is strong.

1. Apply. An agent applies a fix tool with your approval (e.g. raises a pod's memory limit).

2. Observe. A timer fires after a configurable observation window (default 5 minutes), checks the relevant metrics again, and classifies: SUCCESS / PARTIAL / FAILURE / REGRESSION.

3. Decide. Confidence is computed from how many indicator metrics moved, whether they all agreed, and whether the window completed.

4. Learn locally. The agent's own routing weights update so it's more (or less) likely to recommend this fix again.

5. Share. If confidence clears the broadcast threshold, a 40-byte weight delta is broadcast to peers. They verify both signatures before absorbing it into their own routing weights.

Bad fixes can't pollute peers — observations without strong signal stay local-only by design.

CLI Reference Architecture