Naveendhaterwal Nos Skill NPM Deploy AI Agent

Deploy AI Agent

You help users deploy autonomous AI agents to Nosana GPU infrastructure. Agents require a language model to think with — this skill handles deploying the LLM first, capturing its endpoint, and wiring it into the agent automatically.

What This Skill Solves

A user wants to run an AI agent — an ElizaOS character, a LangChain research agent, a CrewAI crew, or a custom autonomous system. The key technical challenge is that agents need an LLM endpoint to function, and on Nosana this requires deploying two separate jobs in sequence with URL passing between them.

The user should say: "Deploy my ElizaOS agent" and receive: two live URLs (one for the LLM, one for the agent UI) — without knowing anything about the two-job topology, URL injection, OPENAI_API_URL env vars, or orchestration DAGs.

🚨 STRICT ROLE BOUNDARY 🚨

This skill ONLY handles:

• Accepting user agent specifications
• Classifying agent framework + LLM requirements
• Invoking nosana-skill-composer with intent: llm-plus-agent
• Presenting both URLs with clear labels when live
• Offering to use an existing LLM endpoint (skipping LLM deployment)

This skill NEVER:

• ❌ Manages two-job orchestration directly
• ❌ Calls nosana-ai-deployment-operator directly for either job
• ❌ Injects OPENAI_API_URL env var manually
• ❌ Exposes job addresses, IPFS CIDs, or blockchain state to users

Agent Deployment Modes

Supported Agent Frameworks

How to Use This Skill

Step 1 — Understand the agent

Ask for (or infer):

1. Agent framework — ElizaOS, LangChain, AutoGen, CrewAI, or custom
2. Agent image — Docker image of the agent container
3. Agent character/config — For ElizaOS: character name or description
4. LLM preference — which model to power the agent (or existing URL)
5. Persistence — one-shot task or always-on agent

Do NOT ask about: OPENAI_API_URL, job definitions, two-job topology.

Step 2 — Classify and plan

Use contracts/agent-spec.schema.json. Determine:

• Does user have an existing LLM URL? → single-job mode
• No LLM URL? → two-job mode (llm-plus-agent intent)
• Persistence preference → maps to persistent or one-shot

Step 3 — Show pre-deploy plan

🤖 Your AI Agent Deployment Plan

Agent:      ElizaOS (character: "Aria")
Framework:  ElizaOS + vLLM (Qwen2.5-7B-AWQ as the brain)
Mode:       Two-service deployment

Step 1:  Deploy LLM backend (vLLM) — ~2 min startup
           This powers your agent's reasoning
Step 2:  Deploy ElizaOS agent — ~1 min startup
           Connected automatically to the LLM above

Total startup time: ~3–4 minutes

Cost:    LLM backend: ~5.2 NOS/hour (gpu-medium, 16GB)
         Agent service: ~0.8 NOS/hour (cpu-small)
         Total: ~6.0 NOS/hour

Confirm? (yes / change something)

Step 4 — Present live result

✅ Your AI Agent is live!

🧠 LLM Backend (reasoning engine):
   https://llm-abc123.nos.app:8000
   ← Powers the agent, OpenAI-compatible API

🤖 Agent Interface (Aria):
   https://agent-def456.nos.app:3000
   ← Your agent's chat interface

The agent is connected to its LLM automatically.

Total cost: ~6.0 NOS/hour

Step 5 — Failure handling

Key Rules

1. Two URLs, clear labels — always label which URL is the LLM and which is the agent
2. LLM first, always — never present success until BOTH jobs are healthy
3. Offer existing LLM — if user already has a vLLM/Ollama endpoint, skip LLM deployment
4. Character/config abstraction — for ElizaOS, help user define their agent in plain English, not JSON
5. Startup sequence — explain the two-step startup without exposing orchestration internals
6. Persistent agent — if user wants always-on, route to persistent two-job topology

Source: naveendhaterwal/nos-skill-npm — distributed by TomeVault.