Developing

lnk-link-harness is Link Harness, the harness a Link agent runs by default: a small router in Rust that answers you, keeps the thread, and calls the tools Link runs for it. How to use it, and why it works the way it does: Link Harness.

This folder, link-harness, is its code. It speaks Link's adapter contract (link_plugin::harness), and Link's release builds it and ships it as one of Link's plugins, at the core's version.

Build and test

With link-core beside this folder (its link-plugin, the conformance kit, and the programs the tests run):

cargo build
# the sandboxed tests skip without bubblewrap, unless LNK_REQUIRE_SANDBOX=1
cargo test
cargo clippy --all-targets -- -D warnings
  • tests/conformance.rs runs the conformance kit, the checks every harness passes.
  • tests/on_the_wire.rs runs it under Link's own lnk agent start, in the sandbox, against a stand-in provider (tests/fixtures/provider.py).
  • tests/memory.rs and tests/sandbox.rs call Link Memory as a tool, built in link-tools beside this folder (LINK_TOOLS, and LINK_CORE for link-core, for other places).

How many agents one machine runs

density/run.sh makes agents with lnk agent new, each on Link Harness with memory, and sends each a message every ten minutes from a fake channel, against a fake model that answers after a fixed delay. It steps the number of agents (1, 5, 20, 50, 100, ...), an hour each, until a message isn't answered within two seconds beyond the model's time, or something fails, and records what each agent costs idle and per turn, beside one OpenClaw and one Hermes Agent. It's run by hand on a machine of its own, never in CI; its header says how, and --dev runs it here on this checkout's programs.