npcpy Agent Framework
Build multi-model agents, coordinated teams, and evolving knowledge graphs in Python.
The README says Agent includes high-impact tools such as sh, python, edit_file, and web_search by default; CodingAgent automatically executes model-produced code, and team members automatically receive configured MCP tools. No least-privilege policy, per-action confirmation, sandbox, scoped authorization, or execution preview is shown, so least_privilege and user_confirmation score 0. The material identifies local and cloud providers, remote MCP, and HuggingFace interactions, but does not fully document what data is transmitted, retained, or exposed, so data-flow transparency is only partial. The release workflow passes the PyPI token through a GitHub secret and uses read-only contents permission, but user-facing credential handling, redaction, and privacy guidance are absent. A publishing action is commit-pinned and CI performs builds, yet most dependencies are unpinned, Ollama is installed through a curl-to-shell pipeline, and lint plus several test groups are non-blocking; dependency security therefore scores 1. Shell execution, file writes, network access, downloads, training, and publishing are visible, but systematic effect controls are not, and no rollback facility is documented. Repository, project, organizational copyright, documentation, and PyPI attribution are clear enough for 2; unknown publisher verification is not treated as suspicious or used to infer unrelated quality.
The README, test files, and CI broadly describe the same NPC, Agent, Team, tool, and multi-provider system. However, some tests are top-level calls that only print responses, while server, Windows, web, and integration checks frequently use continue-on-error or “|| true”; lint is also non-blocking. Self-consistency is therefore only 1. Python 3.10–3.12, local and cloud providers, a lite installation, and package build checks provide ordinary dependency availability, scoring 2, but many capabilities still depend on large downloads, external services, or credentials. Failure reporting is largely limited to pytest output and CI summary messages; no consistent user-facing error taxonomy, recovery guidance, or provider-failure behavior is evidenced, so it scores 1.
The sources cover research, coding, image generation, knowledge graphs, multi-agent work, serving, and structured output, with multiple configurable models and providers; audience/scenario coverage and environment fit each score 2. The advertised surface is extremely broad, while unsupported scenarios, safety boundaries, resource limits, and a complete support matrix are not defined, leaving capability boundaries at 1. Persona directives, tool descriptions, and jinx descriptions help routing, but default tools and natural-language orchestration lack precise authorization or triggering rules, so trigger precision is 1.
The README has substantial sections, collapsible examples, and a project tree, but the supplied material is truncated and does not establish complete navigation, API organization, or operational documentation, so information architecture scores 2. Installation guidance is mostly “pip install npcpy” plus CI commands; optional extras, system dependencies, credentials, and provider setup are not comprehensively explained, resulting in 1. NPC, Agent, ToolAgent, CodingAgent, Team, NPCArray, and jinx terminology is generally consistent, though import paths vary and the concept surface is large, so naming stability is 2. Examples are unusually numerous and concrete, earning 3. No explicit known-limitations section is supplied, scoring 0. The standalone MIT license and README badge agree, earning 3. PyPI/release automation is visible, but no changelog, compatibility policy, or migration notes are shown, so versioning/changelog scores 1. Organizational copyright and an automated release path exist, but named maintainers, support routes, and security ownership are absent, leaving maintenance responsibility at 1.
The framework demonstrates plain, streaming, JSON, Pydantic, multi-agent collection, and server outputs that are generally ready for downstream use, so output usability scores 2, although static output contracts and error forms are incomplete. Combining multi-provider calls, personas, tools, knowledge graphs, and team orchestration offers credible marginal value, scoring 2, but the supplied sources do not establish a thoroughly differentiated advantage over alternatives. Time, monetary, and hardware costs for cloud APIs, searches, large model downloads, image generation, 70B models, and 50-epoch training are barely addressed, so cost-benefit guidance scores 1.
Several capabilities map to concrete README examples, test names, and CI steps, giving partial traceability, but the strong claim that the data layer “ensures compliance through software” lacks an explained mechanism, policy model, or supporting test, so claim traceability is 1. README, tests, and workflows provide some cross-source corroboration for imports, documentation examples, serving, SQL, tools, and package builds, earning 2; many checks are non-blocking and none were executed for this review. Generated example answers and promotional capability claims are not consistently separated from verified facts or guarantees, and the displayed model answers lack validation, so fact/inference separation scores 1.
- CodingAgent automatically executes model-generated code, while the ordinary Agent has shell, Python, file-editing, and web-search tools by default. Add per-action confirmation, tool allowlists, path restrictions, and sandboxing before use outside an isolated environment.
- Remote models, MCP servers, web search, datasets, and media providers may receive prompts, files, or context. The supplied material does not provide a complete data-flow, retention, privacy, or credential-handling account.
- Several CI integration, server, Windows, web, and lint checks are allowed to fail, so the existence of those workflows does not mean the corresponding paths are enforced.
- Dependencies are not shown as locked or vulnerability-scanned, and CI uses a network installation script. Independently audit dependencies, pin versions, and verify the supply chain before deployment.
- The README claim that compliance is ensured through software lacks a traceable mechanism or validation evidence in the supplied sources and should not be treated as a compliance guarantee.
What does this agent do, and when should you use it?
npcpy is a Python library for research and development with multimodal language models, agent systems, and knowledge graphs. Its main components include NPC, Agent, ToolAgent, CodingAgent, Team, and NPCArray for personas, tool use, code execution, orchestration, and parallel inference. The model layer supports local options such as Ollama, llama.cpp, LM Studio, and omlx alongside cloud providers including OpenAI, Anthropic, Gemini, DeepSeek, and MiniMax. Its Context-Agent-Tool layer can combine .npc personas, .jinx workflows, team.ctx configuration, Markdown agent definitions, and MCP servers. Results can be returned as regular responses, streams, JSON, or Pydantic-shaped data, while teams can be exposed through a Flask REST server. Knowledge-graph lifecycles, multimodal generation, fine-tuning, reinforcement learning, and other ML modules make it a broad research and engineering toolkit rather than a hosted turnkey agent.
A developer defines a persona, directive, model, and provider through NPC or a Markdown/.npc file, then selects Agent for bundled tools, ToolAgent for custom functions and MCP tools, or CodingAgent for automatic execution of code blocks produced by the model. Team.orchestrate() coordinates named roles through a forenpc, while NPCArray runs infer, jinx, chain, and consensus operations across multiple NPCs or models. Jinx files describe multi-step pipelines with YAML, Jinja templates, natural-language or Python steps, and values supplied by team.ctx. The library calls local or cloud models, tracks message context, parses streaming chunks, and returns free-form or JSON/Pydantic-structured output; separate interfaces generate images, speech, and video. Its knowledge-graph modules extract facts and concepts from text, assimilate new material, consolidate or prune during sleep, create speculative dream connections, and perform hybrid search; SememolutionPopulation evolves competing graph variants. Applications can run through Python, npcsh, executable .npc/.jinx files, or start_flask_server, and commands such as npc-claude and npc-codex launch external coding tools as team personas.
- A Python team prototyping across Ollama and several cloud APIs can keep the same get_llm_response, NPC, and Team abstractions while changing model and provider settings.
- Researchers studying multi-agent debate or model populations can use NPCArray to collect parallel answers, run personalized critique rounds, and calculate a consensus.
- Engineers building an assistant that must inspect files, execute shell or Python tasks, search the web, and call internal services can combine Agent, ToolAgent, and MCP.
- A research application that needs persistent, searchable memory from documents can use knowledge-graph initialization, incremental evolution, sleep consolidation, dream synthesis, and hybrid retrieval.
- Teams that want reviewable, file-based behavior definitions can store personas in .npc or Markdown files, workflows in .jinx files, and shared settings in team.ctx.
- Applied-ML researchers can experiment with the documented SFT, DPO, diffusion-training, image, audio, and video interfaces within the same package.
What are this agent's strengths and limitations?
- The same core NPC, Team, and response interfaces cover local models and multiple cloud providers, reducing dependence on one model vendor.
- Distinct components cover single personas, bundled tools, custom or MCP tools, coordinated teams, and vectorized model populations.
- .npc, .jinx, team.ctx, Markdown agents, and MCP configuration provide a composable, file-based way to define behavior and workflows.
- The package goes beyond plain chat calls with streaming, JSON/Pydantic output, multimodal generation, knowledge graphs, and training modules.
- Delivery options include a Python library, npcsh, executable workflow files, integrations that launch coding CLIs as personas, and a Flask REST server.
- The breadth of NPCs, teams, Jinx workflows, context files, MCP, and multiple agent subclasses creates a substantial learning and governance surface.
- Full functionality can require Ollama, model weights, ffmpeg, audio libraries, diffusers, transformers, or several external APIs, making environments comparatively heavy.
- Cloud models, remote MCP, web search, and some multimodal operations require network access and credentials; local execution shifts the cost to model downloads and compute.
- CodingAgent automatically executes model-generated code, while Agent exposes shell, Python, and file-editing tools, so production use needs strong isolation and auditing.
- The graph dreaming, population evolution, and training modules are research-oriented, and the source provides no accuracy, stability, resource, or production-scale benchmarks.
How do you install or deploy this agent?
A Python environment is required. Install the base package with:
pip install npcpyChoose extras according to the required surface:
pip install npcpy[lite] # API-provider libraries
pip install npcpy[local] # Ollama, diffusers, transformers, airllm
pip install npcpy[yap] # TTS/STT
pip install npcpy[all] # all extrasFor cloud providers, export the applicable credential, such as OPENAI_API_KEY, ANTHROPIC_API_KEY, or GEMINI_API_KEY. For the documented local Ollama path, install Ollama and run:
ollama pull qwen3.5:2bThe documented Linux system packages for relevant audio, video, and graphics features include espeak, portaudio19-dev, python3-pyaudio, ffmpeg, libcairo2-dev, and libgirepository1.0-dev. On macOS, the listed packages are portaudio, ffmpeg, pygobject3, and ollama.
How do you use this agent?
Make a first local model call:
from npcpy import get_llm_response
response = get_llm_response("Explain quantum entanglement.",
model="qwen3.5:2b",
provider="ollama")
print(response["response"])Create an agent with the default tool set:
from npcpy import Agent
agent = Agent(name="File Operator", model="qwen3.5:2b", provider="ollama")
print(agent.run("Find all Python files over 500 lines in this repo and list them"))Define and orchestrate a team in code:
from npcpy import NPC, Team
coordinator = NPC(name="lead", primary_directive="Coordinate the team. Delegate to @analyst.")
analyst = NPC(name="analyst", primary_directive="Analyze data and report trends.", model="gemini-2.5-flash", provider="gemini")
team = Team(npcs=[coordinator, analyst], forenpc="lead")
print(team.orchestrate("Analyze renewable energy adoption trends")["output"])File-defined teams can be used interactively through npcsh, and .npc or .jinx files can be executed directly. For REST delivery, call start_flask_server with explicit port, CORS origin, history database path, and team directory settings.
How does this agent compare with similar options?
Compared with directly wiring an application to one cloud-model API, npcpy supplies a multi-provider layer plus agents, teams, workflows, and knowledge graphs, at the cost of more configuration and runtime dependencies. Within npcpy, NPC focuses on persona-driven model interaction; Agent adds default tools; ToolAgent accepts custom and MCP tools; and CodingAgent automatically executes code blocks from model responses. For groups of agents, Team emphasizes coordinator-led orchestration through a forenpc, whereas NPCArray emphasizes parallel, chained, and consensus operations over multiple models or personas.