When not to use this

visvoai-core

If you want hundreds of integrations, chains, and a batteries-included ecosystem, use LangChain/LangGraph directly — that's what they're for. visvoai-core is deliberately not a framework: no datastore, no web layer, no auth, no document loaders, no retriever abstractions, no chain composition DSL. It is the ~1,000-line agent↔tools loop every agent product ends up writing — a soft step cap, a tool lifecycle, retrieval for large tool fleets, and a handful of subclass hooks — already hardened by two real consumers, and nothing more.

Use it when you're building a product on the loop and want the sharp edges (recursion deaths, runaway rounds, tool sprawl, lifecycle plumbing) already filed down. Don't use it if what you actually need is the wider LangChain ecosystem's breadth of integrations — layer visvoai-core's loop underneath that ecosystem's tools instead, or skip it and use LangGraph raw if you're not building a product with the concerns above.

visvoai-ai

If you've already committed to exactly one provider and don't need cost visibility, model choice, or a normalized reasoning control, a raw provider SDK (or langchain-openai / langchain-anthropic / langchain-google-genai directly) is simpler and has one fewer layer between you and the vendor. visvoai-ai earns its keep specifically at the moment you support choice — multiple providers, visible per-call costs, or reasoning controls that need to work the same way regardless of which model is selected. If "call one model I already chose" is the whole requirement forever, this package is overhead you don't need.

visvoai-ai also does not attempt one-shot generate/embed calls as a first-class surface — Provider.build() returns a BaseChatModel for the agent loop; embedding and one-shot generation are out of scope by design (a consumer needing them adds methods on a subclass).

Forking instead of depending

Both packages are MIT-licensed — forking is legitimate. Before forking: most "I need to change the behavior" cases are covered by the extension seams documented on this site (AgentRuntime's hooks, a custom Provider), and staying a dependency means you keep receiving upstream fixes. Fork when you need to change the loop's shape in ways the hooks genuinely don't reach — and if you hit that wall, it's worth filing an issue first; it may turn out to be the next hook rather than a fork.