DEV Community: Jamiu Tijani

I turned an Android phone into a Kubernetes worker node

Jamiu Tijani — Tue, 09 Jun 2026 15:57:27 +0000

A few months ago I had a thought: modern Android phones are carrying 8-core ARM SoCs, gigabytes of RAM, and fast storage sitting idle on a desk. What if a standard Kubernetes cluster could just... use them?

That question became DroidNode.

$ kubectl get nodes
NAME                        STATUS   ROLES    AGE
kali                        Ready    master   4d
droidnode-b96a49db497af1eb  Ready    <none>   2h   ← Android phone

standard kubectl apply works and the pod runs on the phone.

The constraints that made it interesting

The hardest constraint was no root. Most container runtimes (Docker, containerd, even podman in its default mode) lean on kernel namespaces and cgroups and both requires elevated privileges on Android.

The second constraint: no modifications to k3s or Kubernetes. The control plane had to stay completely unaware that it was talking to an Android device. From the scheduler's perspective it needed to look like an ordinary Linux worker node.

So the problem became: how do you run arbitrary Linux container workloads on Android, without root, while speaking fluent Kubernetes?

The key insight: proot

proot is a userspace implementation of chroot built on ptrace. Instead of asking the kernel to change the root filesystem (which requires root), proot intercepts every syscall the guest process makes and translates the paths in software.

It's slower than a real namespace-based container runtime, but it works on Android with developer mode enabled.

Basically the flow is :

kubectl apply -f pod.yaml
    → k3s schedules pod to droidnode node
    → DroidNode agent receives pod spec
    → pulls OCI image layers from registry
    → unpacks layers into a rootfs directory
    → spawns: proot -r /path/to/rootfs -w /app /bin/sh ...
    → pod runs, logs stream back, status reported to k3s

Implementing the kubelet API

Kubernetes doesn't care what's running the pods , it just talks HTTP to whatever is registered as the kubelet for a node. So I implemented the parts of the kubelet API that k3s actually uses:

GET /pods — return current pod list
GET /containerLogs/{namespace}/{pod}/{container} — stream logs
POST /run/{namespace}/{pod}/{container} — exec (not yet implemented)

The node registers itself with k3s by creating a Node object in the API server and then sending periodic heartbeat patches to the node's status. As long as the Ready condition stays True and lastHeartbeatTime updates every 30 seconds, k3s treats it like any other node.

Because k3s requires the kubelet endpoint to serve HTTPS with a certificate the control plane trusts. The agent generates its own CA on first run, writes it to disk, and you copy it to k3s once:

adb shell run-as com.droidnode cat /data/data/com.droidnode/files/kubelet-ca.crt \
    > /tmp/android-kubelet-ca.crt
sudo cp /tmp/android-kubelet-ca.crt /etc/rancher/k3s/

After that, every restart reuses the same CA so the trust relationship persists.

OCI image pulling from scratch

I couldn't use any existing container runtime library because they all assume Linux namespaces. So I wrote the OCI registry client from scratch in Rust.

The flow is:

Fetch the image manifest from the registry (Docker Hub, GHCR, etc.)
If it's a manifest list, pick the linux/arm64 platform entry
Fetch each layer blob (gzipped tar)
Unpack layers in order, applying whiteout files (deletions) as we go
Write a sentinel file so we know the rootfs is ready next time

The whiteout handling was surprisingly fiddly. OCI layers express file deletions as special .wh. prefixed files (you have to process them in layer order or you end up with files that should have been deleted still present in the rootfs).

Another notable issue is hardlinks across layer boundaries. Android's internal storage filesystem doesn't support cross-directory hardlinks in some configurations, so I had to fall back to a copy when link() fails:

match std::fs::hard_link(&src, &dst) {
    Ok(_) => {}
    Err(_) => { std::fs::copy(&src, &dst)?; }
}

The architecture: The Standard

The Rust agent follows Hassan Habib's The Standard strictly:

Brokers → Foundation Services → Orchestration Services → Exposers

Brokers wrap exactly one external system (OCI registry, filesystem, proot binary, k8s API). No logic, no conditionals.
Foundation services each do one thing (pull an image, unpack a layer, run a workload).
Orchestration services coordinate foundation services (reconciliation loop, image pipeline).
Exposers are thin entry points (the kubelet HTTPS server, the Android foreground service).

Enforcing this made the codebase much easier to test in pieces — I could validate the OCI registry broker against Docker Hub independently, then layer the image pull service on top of it, and so on.

The Android side: Kotlin foreground service

On Android, a foreground service is the only reliable way to keep a process alive without root. The Kotlin layer is intentionally thin — it just:

Starts the Rust agent as a native subprocess
Holds a wake lock so Android doesn't kill it under memory pressure
Monitors battery and network state
Provides a debug UI (tap the notification to see live logs, node status, and pod events)

The Rust agent writes to stdout; Kotlin tails it and feeds lines into a ring buffer that the debug UI reads. No JNI — clean process boundary.

What actually works today

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: hello-android
spec:
  nodeName: droidnode-<your-device-id>
  restartPolicy: Never
  containers:
    - name: hello
      image: alpine:latest
      command: ["/bin/sh", "-c"]
      args: ["echo hello from DroidNode; uname -m"]
EOF

kubectl logs hello-android
# hello from DroidNode
# aarch64

I've tested with Alpine, Python HTTP servers, and stefanprodan/podinfo. Images with a WORKDIR set work correctly — the agent reads the WorkingDir field from the image config and passes it to proot's -w flag.

Known limitations

This is a working proof of concept, not a production runtime. The main gaps:

Area	Status
Multi-container pods	Only first container runs
`restartPolicy: Always`	Not implemented
Volume mounts	Source path mapping is broken
Network isolation	Containers share host network
`kubectl exec`	Not implemented
Load balancer pods (svclb)	iptables fails inside proot

All of these are tracked as open issues if you want to pick one up.

What's next

The most interesting unsolved problem is network isolation. Right now every container shares the Android device's network interface. Implementing proper pod networking without root is genuinely hard, the closest viable approach is probably a userspace TCP proxy similar to what k3s does for services.

Try it

The repo is at github.com/c0d3g3n13/droidnode. You need a device with developer mode enabled, an ARM64 Android phone (API 26+), and a k3s cluster to connect it to.

If you find it interesting and want to contribute, the open issues are a good place to start. The architecture is strictly layered so most features can be added without touching much existing code.

AATP: A Case Study in Designing a Protocol for Agentic AI Communication

Jamiu Tijani — Fri, 04 Apr 2025 14:26:33 +0000

As I build the Agentic AI Transport Protocol (AATP), I’m exploring how agent-to-agent communication should work in a world of intelligent, autonomous systems. This is a preview of what’s coming—and why it matters.

🚧 Why I’m Building AATP

Multi-agent systems are no longer theoretical—they’re becoming foundational to how modern AI applications are designed.

In these ecosystems, agents aren’t just prompts or functions—they're collaborative entities with roles, goals, and memory.

But under the hood, their communication still relies on:

Generic REST APIs
WebSocket workarounds
Heavy message queues

None of these were designed for agents.

I saw an opportunity to solve this with a dedicated, agent-focused protocol—something fast, browser-native, memory-aware, and purpose-built.

That’s the origin of AATP: the Agentic AI Transport Protocol.

🎯 The Problem I’m Solving

Even with frameworks like LangGraph or CrewAI, agent communication is loosely defined and often hard-wired. I needed something that offered:

✅ Structured, role-based messages
✅ Context passing without bloated prompts
✅ Compatibility with the browser and edge environments
✅ Clean hooks for memory and routing

AATP is my answer to these needs.

🧠 The Vision Behind AATP

I'm designing AATP around four core ideas:

Intentful Messaging

Agents should declare their goal, not just send data.
Memory by Reference

Instead of sending massive context, agents share memory keys or vector IDs.
Browser-First

No backend required—just a clean JS SDK that works out of the box.
Agent Identity & Routing

Agent URIs should be as meaningful as email addresses, like agent://sales@aidra.

🧩 Planned AATP Packet Format

{
  "from": "agent://planner@aidra",
  "to": "agent://writer@aidra",
  "intent": "generate_outline",
  "conversation_id": "c987-42ef",
  "memory_token": "qdrant://aidra/convo/c987",
  "payload": {
    "type": "text",
    "content": "Please create a 3-point summary based on our last discussion."
  },
  "trace": ["planner", "router"]
}

Each field carries meaning:

intent gives purpose
memory_token provides continuity
trace helps with debugging and feedback loops

🛠️ Architecture (In Progress)

Here’s the early sketch of what I’m building:

Layer	Tech (Planned)
Transport	HTTP/2 + ProtoBuf or Cap’n Proto
Client SDK	TypeScript (browser) + Go (backend)
Memory	Qdrant / Pinecone / Redis
Routing	LangGraph or custom JS planner
Security	HMAC, JWT, scoped agent permissions

It’s modular so developers can swap in their own memory systems, routers, or signing layers.

🧪 Prototyping and Testing So Far

I’ve been testing AATP concepts using:

LangGraph state injections to simulate messages
Browser-only agent demos that route between roles
Memory referencing with Qdrant for persistent history

Early Takeaways:

Embedding memory tokens is way more efficient than bloating prompts
Explicit intent fields improve readability and routing logic
Client-side agents need a zero-config protocol to scale

🧩 Where AATP Fits

Even in its early stage, AATP could power projects I’m already working on, including:

✅ AIDRA Platform

Multi-agent routing in the browser
Direct Lambda ↔ browser agent communication
Qdrant memory continuity with each exchange

✅ Indexer Pipelines

Trigger downstream agents like agent://parser or agent://validator
Carry vector payloads for semantic traceability

🔐 What I’m Planning for Security

I want AATP to be safe out of the box. Planned security features include:

Role-based agent URIs
Signed messages (HMAC or JWT)
Namespace-based rate limits
Optional auth.verify() middleware on both ends

The goal is traceable, decentralized, and secure agent messaging.

🧠 My Hope for AATP

I’m not just trying to build a protocol—I’m trying to change the default for how agents interact.

If AATP succeeds:

Agents will communicate natively without backend glue
Memory and purpose will travel through every hop
Agent-to-agent workflows will be as simple as emails—but 10x faster

📅 What’s Next

In the coming months, I plan to:

Finalize the packet schema
Release the TypeScript SDK
Integrate AATP into a live AIDRA workflow
Open up an alpha version for early users

✍️ Final Thoughts

Too often, agent communication is treated as an afterthought. But I believe it deserves a protocol of its own—one that speaks the language of roles, memory, and purpose.

AATP is still in the lab. But I’m confident it will become a foundational layer for the agentic future I’m helping build.

Agents shouldn’t just speak to us—they should speak to each other.

AATP is how I’m making that possible.

Implementing LangGraph for Multi-Agent AI Systems

Jamiu Tijani — Fri, 04 Apr 2025 14:07:03 +0000

Learn how to orchestrate multiple AI agents in a coherent, collaborative system using LangGraph, vector databases, and thoughtful architectural patterns.

The rise of agentic AI has opened the door to building intelligent, multi-agent systems that can reason, communicate, and collaborate toward shared goals. But coordinating these agents effectively—while keeping memory, state, and context intact—is a different kind of challenge altogether.

Enter LangGraph.

LangGraph offers a flexible, graph-based execution model for building multi-agent workflows on top of powerful LLMs. It brings modularity, memory management, and dynamic control flow to the table—key ingredients for scaling agent architectures.

In this article, we’ll explore how to implement LangGraph in a production-grade, multi-agent system powered by OpenAI models, vector databases, and custom tool integrations.

🚀 Why Multi-Agent Systems?

Traditional LLM applications are often single-agent and synchronous—good for simple tasks, but limited when complexity rises.

Multi-agent systems allow:

Task specialization (e.g., researcher vs coder vs tester agents)
Parallel processing of sub-tasks
Negotiation and delegation among agents
Dynamic workflows based on agent feedback

But... these benefits introduce new challenges:

How do agents communicate?
How do you manage shared memory and state?
How do you coordinate dynamic control flow?

LangGraph solves exactly this.

🧠 What is LangGraph?

LangGraph is an open-source library that extends LangChain by allowing you to define stateful agent workflows using directed acyclic graphs (DAGs) or finite state machines.

Key Features:

🔁 Loops and recursion for iterative agent behavior
💬 Agent messaging support
🧱 State abstraction for long-running contexts
🧠 Easy plug-in for vector stores, memory, and tools

🧩 Architecture Overview

Here’s what a typical LangGraph-powered multi-agent system looks like:

┌──────────────┐      ┌──────────────┐
│  User Input  ├─────▶│ Entry Agent  │
└──────────────┘      └────┬─────────┘
                           │
                   ┌──────▼──────┐
                   │  Router Agent│
                   └────┬───────▲┘
                        │       │
         ┌──────────────▼─┐ ┌───▼────────────┐
         │ Research Agent │ │ Codegen Agent  │
         └─────────────▲──┘ └──────▲─────────┘
                       │           │
                 ┌─────┴───────────▼─────┐
                 │  Evaluation Agent     │
                 └────────┬──────────────┘
                          ▼
                  ┌──────────────┐
                  │  Final Output│
                  └──────────────┘

Each agent is implemented as a node in a LangGraph and can read/write to shared state.

🛠️ Setting Up LangGraph

Install the required dependencies:

pip install langgraph langchain openai qdrant-client

Optional (if you use tools or retrievers):

pip install beautifulsoup4 faiss-cpu

📦 Step 1: Define the Shared State

LangGraph passes a shared state dictionary to each node.

Here’s an example schema:

state = {
  "input": "",         # user input
  "history": [],       # full agent interaction history
  "documents": [],     # retrieved docs from vector store
  "code": "",          # generated or modified code
  "evaluation": ""     # output from evaluator agent
}

Use a dataclass or Pydantic model if you prefer strict typing.

🤖 Step 2: Define Your Agents (Nodes)

Each agent is a function that receives and returns the updated state.

def researcher_agent(state):
    query = state["input"]
    docs = vector_store.search(query)
    state["documents"] = docs
    state["history"].append("Researcher retrieved docs.")
    return state

def coder_agent(state):
    prompt = build_prompt(state["documents"])
    code = openai.ChatCompletion.create(...).choices[0].message["content"]
    state["code"] = code
    state["history"].append("Coder generated code.")
    return state

🔁 Step 3: Define Graph Flow

LangGraph supports dynamic branching based on conditions.

from langgraph.graph import StateGraph

graph = StateGraph()

graph.add_node("researcher", researcher_agent)
graph.add_node("coder", coder_agent)
graph.add_node("evaluator", evaluator_agent)

graph.set_entry_point("researcher")

graph.add_edge("researcher", "coder")
graph.add_edge("coder", "evaluator")
graph.set_finish_point("evaluator")

app = graph.compile()

📚 Step 4: Integrate with Vector Stores

LangGraph pairs well with vector databases like Qdrant, Pinecone, or Weaviate for memory retrieval.

Example Qdrant setup:

from qdrant_client import QdrantClient

qdrant = QdrantClient(url="http://localhost:6333")
retriever = qdrant.as_retriever("my_collection")

vector_store = RetrieverWrapper(retriever)

Pass documents between agents via shared state.

🔍 Step 5: Memory and Traceability

To maintain persistent agent memory, integrate:

Conversation history into prompts
Document memory from vector search
Intermediate state logging (audit trail)

Example:

state["history"].append({
  "agent": "Evaluator",
  "action": "Scored output at 9/10"
})

For observability, consider emitting events to a queue or logging system.

💡 Advanced: Branching and Feedback Loops

LangGraph supports conditional logic like:

def decision_node(state):
    if "bug" in state["evaluation"]:
        return "coder"  # loop back to codegen
    return "final_output"

Loop until success!

🔒 Security and Guardrails

For production-grade systems:

Use function-calling or tool-calling for safe agent actions
Validate user inputs and prompt outputs
Add rate limits and timeout handling
Monitor token usage and cost alerts

🧪 Testing the System

LangGraph can be easily tested with mock agents:

def mock_agent(state):
    state["history"].append("Mock agent called")
    return state

You can simulate flows with app.invoke():

result = app.invoke({"input": "Build a weather app"})
print(result["code"])

🧠 Real-World Use Cases

Customer Support AI: Router agent + Knowledge retriever + Response generator
Research Assistant: Planner agent + Web scraper + Summarizer
Code Review Bot: Linter agent + Fixer agent + Unit test generator

🧩 LangGraph vs Traditional Pipelines

Feature	LangGraph	Traditional Chain
Multiple agents	✅ Yes	🚫 Limited
Branching logic	✅ Yes	🚫 Hard-coded
Shared state	✅ Explicit	❌ Implicit
Debuggability	✅ High	⚠️ Difficult
Looping support	✅ Native	🚫 Hacky

✅ Conclusion

LangGraph provides a clean, scalable, and debuggable way to coordinate multiple AI agents with shared context and dynamic flow control. When paired with a robust vector database and tool integrations, it unlocks a new generation of cooperative, intelligent systems.

Start small. Model your agent flows. Think in graphs, not just chains.