Automate it
Agents with tools, skills, MCP & native provider tools
Configurable AI agents that call your tools, run Anthropic-standard skills in a Docker sandbox and federate across MCP servers. Each provider's own server-side tools can be switched on per agent.
Your tools, your logic
Define custom tools in Groovy with helpers for HTTP calls, in-process Turing search and conversation slots. Tools hot-reload and can be tested from the admin without a restart.
Anthropic-standard skills in a sandbox
Drop in a skill folder (SKILL.md + scripts) and Turing runs it in an isolated Docker sandbox with progressive disclosure. It is the same skill format Claude uses, executed against a per-conversation workspace.
MCP in both directions
Connect agents to Model Context Protocol servers (with cross-vendor federation), and expose Turing's search as an MCP server so any MCP-aware client can query your content.
Built-in code interpreter & chat flows
Run Python in a hardened sandbox (native or Docker), and orchestrate multi-step conversations with a declarative flow DSL that includes slots, form capture, A/B testing and human handoff.
npx @viglet/turing-cli init my-search
cd my-search
npx @viglet/turing-cli dev # local stack
npx @viglet/turing-cli deploy # push agents, flows, tools & skillsTurn on the tools your model already has
OpenAI, Anthropic and Gemini ship tools that run in their own infrastructure. Turing wires them into the agent loop (opt-in per agent, no glue code, no extra crawler) and routes their citations into the same source-chip UI as your own search.
Web search & grounding
The model searches the live web (and Google grounding on Gemini) and grounds its answer. Citations flow into the same source-chip UI as your own RAG.
Code execution
A managed Python sandbox runs alongside your own code interpreter for charts, data wrangling and computed answers, rendered inline.
Computer use
A multi-turn screenshot/action loop behind a pluggable driver seam. The model browses and operates a UI to complete a task, with the same contract across all three vendors.
URL / web fetch
The model pulls a URL or PDF named in the prompt directly in the provider's infrastructure, with no Turing crawler in the path.
Image generation
Images are generated inline in the answer as self-contained data URIs, with no separate artifact endpoint to host.
File search
Retrieval over a provider-hosted vector store, available as a built-in tool next to Turing's own search.
Strictly opt-in via a two-level capability gate, so your existing agents stay unchanged. Provider availability as of 2026.3.
Questions teams ask
- What is the difference between a tool and a skill?
- A tool is a function the agent calls, written in Groovy and run in-process. A skill is a folder (a SKILL.md plus scripts) that the agent discovers and runs in an isolated Docker sandbox, in the same format Claude uses.
- Can an existing OpenAI app talk to a Turing agent?
- Yes, through the OpenAI-compatible gateway once it is enabled. Point the app's base URL at Turing and ask for the model turing-agent:<id>; the agent answers with its own prompt, tools and grounding.
- Can an agent keep our brand voice across LLM providers?
- Attach a persona. It carries the required and forbidden vocabulary and the brand facts, and it stays with the agent when you change its LLM.
- Do the provider's server-side tools need code?
- No. Web search, web fetch, code execution and computer use are switched on per agent, once an admin has enabled them on the model instance.