# Connect a Function with EasyRemote | EasyNet Docs

Source: https://easynet.run/docs/connect/function

Docs / Connect a function
[Docs](https://easynet.run/docs)

Docs

# Connect a function

Expose an existing function through EasyRemote. The current implementation uses Python; the connection model is function-level, not Python-only.

Register one owned Python function as a typed provider binding. Its implementation and dependencies stay with the Provider; declared inputs and returned output cross the call boundary.

Source workspace · paired Runtime

Live function setup needs a complete, compatible source workspace, a paired Runtime, and a compatible Hub. Technical Alpha offers guided help, not permission to read the public repositories.
[Request Technical Alpha](https://easynet.run/pilot)[Check the setup requirements](https://easynet.run/docs/connect/function#runtime-preflight)[All connection paths](https://easynet.run/docs/connect)

Step 0

## Prepare the Runtime first.

A function Provider depends on a paired, running Runtime. Complete the Runtime preflight before installing or starting EasyRemote on the provider machine.
[Open the Runtime guide](https://easynet.run/docs/connect/runtime?continue=function#run-guide)

## Run this guide
Function exampleA minimal quotation functionContinue the synthetic record example

Outcome

Register one owned Python function as a typed provider binding. Its implementation and dependencies stay with the Provider; declared inputs and returned output cross the call boundary.

Before you run it

Prepare compatible EasyRemote, EasyNet-Cli, and EasyNet-Axon sibling source checkouts, a compatible Hub, and a paired, running local daemon. Technical Alpha provides guided setup. Reading public source does not install the required SDK dependency chain or prepare this runtime environment.

### Give your coding agent the whole setup task

Includes the selected mode, prerequisites and checks. Copying does not run anything. Context tasks cover folder mapping only; Windows installation remains on hold.

Preview task
zsh · provider preflight

```
easynet runtime status
cd "/absolute/path/to/easynet-workspace/EasyRemote" &&
  uv sync --frozen &&
  uv run easyremote doctor
```

provider.py · save this function boundary

```
from easyremote import ComputeNode

node = ComputeNode()

@node.register
def quote(quantity: int) -> dict:
    return {"quantity": quantity, "total": quantity * 19}

node.serve()
```

zsh · start the Provider

```
# Save the previous block as provider.py, then keep this terminal open.
uv run python provider.py
```

zsh · verify from a second terminal

```
# In a second terminal:
easynet ability list --node local --format json
```

## Verify the result and boundary

Success looks like

`easyremote doctor` first confirms the local transport. While `provider.py` remains running, `ability list --node local --format json` must show the Provider binding in the local catalogue.

Still separate

This guide assumes a complete, compatible development workspace; a clean-machine install from public package registries has not been verified. Local activation is not Realm visibility; the owning Runtime/product must still confirm directory publication before another Agent can discover it.
[Request guided function setup](https://easynet.run/pilot)

### One provider. A separate caller. Recorded results.

In a development test, one Runtime published Python functions and a second Runtime discovered and called them. These are synthetic test functions, separate from the guide example above.

Publish functions on the provider.

Discover and call them from the caller; receive structured values and a finite stream.

Stop the EasyRemote provider process; its eight functions disappear from the caller’s directory.

Inspect three recorded calls

```
[
  {
    "call": "add(2, 3)",
    "result": {
      "function": "add",
      "kind": "sync",
      "value": 5
    }
  },
  {
    "call": "total(1, 2, 3, 4)",
    "result": 10
  },
  {
    "call": "countdown.stream(3)",
    "result": [
      {
        "tick": 3
      },
      {
        "tick": 2
      },
      {
        "tick": 1
      }
    ]
  }
]
```

6 September 2026 · Two Linux Docker device Runtimes under the same user, on one physical host. No LLM or model was used. This does not verify public networks or cross-owner permissions.

The caller warmed its catalog first. Withdrawal checks directory absence, not later rejection of an old address. Selected receipt checks use Runtime verification, not independent signature verification. Source revisions include uncommitted changes.
[Download the scoped test summary (JSON)](https://easynet.run/evidence/function-two-runtime-2026-09-06.json)