Skip to content

Forum

AI Assistant
Notifications
Clear all

Switched from a monolithic agent to micro-agents on NEAR - tradeoffs

1 Posts
1 Users
0 Reactions
0 Views
(@cloud_sec_ken)
Eminent Member
Joined: 1 week ago
Posts: 17
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
  [#1236]

Just wrapped up migrating a core IronClaw workflow from a single, beefy agent running in our enclave to a swarm of smaller, NEAR-based micro-agents. The pitch was compelling: distribute logic, leverage on-chain state for coordination, reduce our enclave's attack surface. Reality, as usual, is messier.

The big win is isolation. A bug in one agent function (like a data fetcher) no longer automatically compromises the entire credential vault. We're now modeling each discrete task as its own NEAR account/contract, which *feels* cleaner. But the trust model gets weird fast. Our secure enclave now has to talk to NEAR's RPC, manage multiple agent private keys (stored off-chain, but accessed via the enclave), and trust NEAR's runtime integrity for agent logic execution. You've traded a monolithic complexity for a distributed systems complexity.

Here's a snippet of the new interaction pattern. The enclave becomes the orchestrator, signing and sending transactions for these micro-agents:

```rust
// Example: Enclave calling a NEAR micro-agent (data fetcher)
let action = FunctionCallAction {
method_name: "fetch_and_validate".to_string(),
args: serde_json::to_vec(&FetchArgs { url }).unwrap(),
gas: 100_000_000_000_000, // Easy to blow budget here
deposit: 0,
};

let tx = Transaction {
signer_id: micro_agent_account_id,
public_key,
nonce,
receiver_id: micro_agent_account_id,
block_hash,
actions: vec![Action::FunctionCall(action)],
};
// Sign inside enclave, send to NEAR RPC
```

**Hidden costs & immediate concerns:**

* **Gas Accounting:** Suddenly you're a gas farmer. Each micro-interaction costs. That "cheap" NEAR transaction adds up across hundreds of agents, per execution cycle. Our cost monitoring went 📈.
* **IAM... but on-chain:** Permissions are now about contract methods and attached deposit. Misconfiguration means an agent can be drained of its attached NEAR balance, or called by unauthorized frontends.
* **Latency Chain:** Enclave -> NEAR RPC -> Consensus -> Execution -> Callback. Adds significant delay compared to in-enclave function calls. Not great for real-time response agents.
* **New Attack Surface:** The NEAR RPC endpoint is now a critical dependency. If compromised or MITM'd, your agent transactions could be tampered with. Also, you're trusting NEAR's validators more than you might think.

The paradigm shift is real, and the fine-grained security *can* be worth it. But it feels like we've swapped a big, hardened vault for a fleet of smaller, easier-to-lose wallets. The security properties now hinge entirely on our enclave's key management and the correctness of those on-chain contract ACLs.

Anyone else gone down this path? How are you handling the key lifecycle for dozens of micro-agent accounts? Are we just reinventing a weird, blockchain-based task queue with extra steps?


- ken


   
Quote