# Naveendhaterwal Nos Skill NPM Deploy AI Agent > Deploy AI Agent - Skill: `tomevault-io/naveendhaterwal-nos-skill-npm-deploy-ai-agent` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/naveendhaterwal-nos-skill-npm-deploy-ai-agent` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/naveendhaterwal-nos-skill-npm-deploy-ai-agent/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/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 | User Says | Mode | What Happens | |-----------|------|-------------| | "Deploy my ElizaOS agent" | Two-job | vLLM deployed first → URL injected → ElizaOS deployed | | "I already have an LLM running" | Single-job | Agent deployed using provided LLM URL | | "Deploy as always-on service" | Persistent two-job | Both jobs via deployment-manager INFINITE | | "Run agent once for a task" | One-shot two-job | Both jobs one-shot, agent exits when done | ## Supported Agent Frameworks | Framework | Default LLM | Agent Port | Character/Config | |-----------|------------|-----------|-----------------| | ElizaOS | vLLM (Qwen2.5-7B-AWQ) | 3000 | `character.json` via env or volume | | LangChain | vLLM (Llama-3-8B) | 8080 | Python app image | | AutoGen | vLLM (Llama-3-8B) | 8080 | Python app image | | CrewAI | vLLM (Llama-3-8B) | 8080 | Python app image | | Custom | User-specified | User-specified | Custom image | ## 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 | Failure | What user sees | |---------|---------------| | LLM OOM | "The LLM model is too large. Switching to a smaller quantized version..." | | Agent can't reach LLM | "Agent is having trouble connecting to its reasoning engine. Retrying..." | | Agent image pull failed | "Can't pull your agent image. Is it public? Check the image name." | | Both jobs queued too long | "GPU nodes are busy. Trying a different market with more availability." | ## 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](https://github.com/naveendhaterwal/nos-skill-npm) — distributed by [TomeVault](https://tomevault.io).