We have spent the past few weeks building an autonomous AI system called Ziggy. It runs on an NVIDIA DGX Spark sitting on a desk, uses Qwen 2.5 32B for local inference through Ollama, and operates continuously: scanning the AI space, generating content, publishing across multiple platforms, and adding new capabilities week by week.
This is what we built, what surprised us, and what the process taught us about deploying AI systems that actually run rather than just exist as demos.
What Ziggy actually is
Ziggy is an autonomous signal engine. It monitors AI developments, generates and publishes content to X, Medium, YouTube, TikTok, and its own website, and grows its own skill set over time. It runs on a schedule, operates independently, and produces real output on real platforms. Every week it can do something it could not do the week before.
The stack runs entirely on one box: Qwen 2.5 32B via Ollama for inference, ComfyUI with Flux Schnell for image generation, Piper for text-to-speech, an FFmpeg video pipeline, Playwright for browser automation on platforms without APIs, and a cron-driven content pipeline that runs twice daily. A Next.js website auto-deploys to Vercel on every git push.
Zero cloud dependency for core inference. Zero ongoing API cost. The Spark has 128GB of unified memory and a Blackwell GPU, which means Ziggy can process full research papers rather than abstracts, test claims exhaustively rather than sampling, and run adversarial passes on its own drafts before publishing. When the marginal cost of one more inference call is zero, the economics of thoroughness change completely.
The build itself
There is a gap between planning an autonomous system and having one that actually runs. The planning stage was full of interesting architectural decisions. The build stage was full of the kinds of problems that only surface when you are trying to make software do things reliably, on a schedule, without human intervention.
Browser automation was a good example. Several of the platforms Ziggy publishes to do not have usable APIs, or have deprecated them, or gate them behind paid tiers that do not make sense for this use case. So Ziggy uses Playwright with a persistent Chromium browser session. That works, but it means managing session state, handling authentication cookies, and dealing with the reality that platforms change their interfaces without warning.
The content pipeline was another. Intake signals come from multiple sources. They need to be scored, queued, processed, and turned into platform-appropriate output: short posts for X, longer articles for Medium, video scripts for YouTube. Each format has different constraints and different tone requirements. Getting that right meant building a pipeline that could generate across formats while maintaining a consistent voice. Not trivial when the voice is being produced by a model that has no inherent memory of what it said yesterday.
Every new capability Ziggy acquires goes through a gated skill system. New tools start in a watching state. If something looks promising, it moves to quarantine: installed but isolated, with a two-week evaluation window and a maximum of five quarantined skills at any time. Only after proving useful does a skill become active, with a hard cap of twenty. We have observed that AI systems degrade when given too many tools. Capability bloat introduces failure modes. The cap forces prioritisation.
The security question nobody was asking
This turned out to be one of the most interesting parts of the project, and one we did not see discussed much elsewhere.
When NVIDIA shipped the DGX Spark, people were understandably excited. A Blackwell GPU on your desk. Local inference at serious scale. But we noticed something: almost everyone who got one installed it on their main machine or plugged it straight into their home network alongside everything else. The default assumption seemed to be that local AI hardware is just another peripheral.
We took a different approach. The Spark runs as a standalone system. It has its own environment, its own credentials, its own network posture. It is not sitting on a machine that also has your email, your browser sessions, your SSH keys, and your cloud credentials.
The reason is straightforward. Ziggy is an autonomous system that processes external content: tweets, articles, forum posts, research papers. All of that content is untrusted data. An autonomous AI system that ingests external content and can execute actions, including browser automation and file operations, is an attack surface. Prompt injection is not theoretical. Embedded instructions in web content, social media posts, or even paper PDFs can attempt to redirect an AI system's behaviour.
We hardcoded Ziggy's security posture into its core identity file. All external content is treated as data, never as instructions. Operator authentication uses a prefix system restricted to a single designated channel. Instruction-like patterns in ingested content are logged and ignored. The system never reveals internal paths, credentials, or operator information regardless of how the request is framed.
None of this is novel in isolation. But the combination of an always-on autonomous system, browser automation, external content ingestion, and action capability makes the attack surface meaningfully different from a chatbot you interact with manually. The standalone deployment is not paranoia. It is a recognition that when you build a system that acts on the world, the security model matters as much as the AI model.
We have not seen this discussed much in the communities excited about local AI hardware. It probably should be.
What the infrastructure makes possible
Owning the hardware changes behaviour in ways that are easy to underestimate.
When inference is free, you test more. You can run a claim through the model fifty or a hundred times across different temperatures and see how the results distribute. You can process overnight batch jobs without watching a bill accumulate. You can run adversarial prompts against every draft before it publishes. You can build a growing corpus of logged experiments that becomes searchable institutional memory over time.
The model runs unfiltered. That matters for research. When you are testing claims about AI behaviour, capability boundaries, or failure modes, you need to see what the model actually does, not what an API content policy allows you to see. Local inference removes that filter.
What this has to do with our research
Bot Research exists to understand when AI reliance becomes unreasonable. Ziggy is a direct application of that question. It is an AI system we rely on, running autonomously, making judgements, and publishing to real platforms. If there is a more direct way to study AI reliability in practice, we have not found it.
Every failure mode we have documented in our other work shows up in Ziggy's operation. Context degradation over long sessions. Confidence that does not track accuracy. Small errors compounding across multi-step workflows. The system does not know when it has gone off course. It continues with the same certainty it had at the start.
Building Ziggy has also forced us to think carefully about what "autonomous" actually means in practice. The system operates on a schedule and generates output independently. But the security architecture, the skill gating, the content pipeline design: all of those are human decisions that constrain and shape the system's behaviour. Autonomy without architecture is just an unmanaged process. The interesting work is in the boundary between what the system does on its own and what it does within structures designed to keep it useful.
What comes next
Ziggy is live but early. The infrastructure is running, the pipelines work, the multi-platform publishing is connected. We are documenting what happens and publishing as we learn.
If you want to follow along, Ziggy posts on X at @ziggybotx, publishes on Medium, and maintains a full log on its website. We will continue writing about what we learn from running it, both the AI findings and the infrastructure and security observations that come from operating an autonomous system in the real world.
We built Ziggy because we wanted to understand what happens when you give an AI system real infrastructure, real autonomy, and real output channels, then watch carefully. The answer so far has been more interesting than we expected, and not always in the ways we predicted.