I Built Autonomiq: A Local AI Research Agent That Lets You Walk Away

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Research can turn into hours of switching between browser tabs, collecting sources, extracting information, comparing findings, and writing reports. I wanted to explore a different workflow: what if I could delegate that process to an AI agent, leave my desk, and return when the work was ready?

That idea became Autonomiq, a local-first autonomous AI research workspace built for students, developers, and researchers who want to automate repetitive knowledge work without constantly watching a chat window.

Autonomiq takes a research objective, prepares a plan, searches for sources, extracts content, indexes evidence for retrieval, analyzes the collected material with a local language model, and generates a structured Markdown report. It can also generate an audio digest so the user can listen to the summary away from the screen.

I designed the experience around three principles:

• Delegate, don't babysit. A task should have a lifecycle independent of the browser interface.
• Keep the AI replaceable. Local model inference should not depend on a single proprietary LLM API.
• Make the work inspectable. Users should be able to see execution stages, sources, and generated artifacts.

The goal is not to create another chatbot that encourages longer conversations. It is to make the time spent supervising repetitive research shorter.

Code

TejasRawool186 / Autonomiq

Autonomiq is a local-first autonomous AI workspace designed to execute digital tasks on a user's computer while minimizing the need for continuous human supervision.

Autonomiq

A Local-First Autonomous AI Workspace
"Your AI works. You live."

Built for Hacktoberfest 2026 Open-Source AI Challenge.

---

🌟 Overview

Autonomiq executes long-running digital research tasks on your computer while minimizing continuous screen time. Users submit tasks in natural language, review an execution plan, and the system autonomously conducts web research, document parsing, RAG embeddings, analysis, and report generation in the background.

With Away Mode and durable execution (via Temporal), you can submit a task, close your browser, leave your desk, and return to completed source-backed reports and an audio digest.

---

🏗️ Architecture & Modules

Autonomiq/
├── backend/                       # FastAPI Server & AI Execution Engine
│   ├── app/
│   │   ├── api/                   # REST Endpoints (Tasks, Documents, Health)
│   │   ├── models/                # SQLite State & Entity Models
│   │   ├── schemas/               # Request/Response Data Contracts
│   │   ├── agent/                 # LangGraph Multi-Node Workflow
│   │   │   └── nodes/             #

…

View on GitHub

The repository contains a React and TypeScript frontend, a FastAPI backend, task and artifact storage, research workflow modules, local vector retrieval, and integrations for search, model inference, tracing, and audio generation.

The implementation and setup notes are available in the repository, including the environment configuration example and the software requirements specification.

The Problem

Imagine researching open-weight AI models for a project. You need to find relevant pages, compare model capabilities, extract hardware requirements, organize the evidence, and turn everything into a report.

A conventional workflow requires repeated manual steps. A chat-based AI workflow can help with individual steps, but the user may still need to collect sources, provide documents, move information between tools, and assemble the final output.

Autonomiq approaches the problem as a workflow rather than a single prompt. The user describes the desired result, and the application coordinates a sequence of research and processing stages.

There is also a privacy consideration. Research material and local documents are not always suitable for uploading to a third-party LLM service. Running the language-model inference locally gives the user more control over where that processing happens.

That does not eliminate every external dependency. Live web search still requires a search provider, and the optional audio integration uses an external service. The distinction matters: local inference and online research are separate parts of the system.

The Idea

The central idea behind Autonomiq is simple: give an AI agent a task that takes time, let the computer perform the work in the background, and return to the result instead of watching every step.

The application is built around a task-oriented interface rather than an open-ended chat. A task has an objective, an execution plan, a sequence of processing stages, sources, and generated artifacts.

The user-facing experience includes Away Mode, task monitoring, source attribution, and an audio digest. The backend keeps task execution separate from the frontend so that closing the browser does not inherently cancel the work, provided the backend worker remains active.

This is my interpretation of the Touch Grass theme. The application does not need to identify a bird or plan a hike to encourage time away from the screen. It can address another source of screen time: supervising repetitive computer work.

How It Works

The research workflow is organized into six primary stages.

1. Plan: The planner uses the configured local model to create a structured research plan and search queries.
2. Search: The researcher calls SerpApi to collect candidate web results.
3. Extract: The extraction stage uses BeautifulSoup-based tooling to retrieve and normalize webpage content.
4. Index: The indexer chunks collected content, creates embeddings, stores them in Qdrant, and retrieves relevant passages.
5. Analyze: The analyst sends the retrieved evidence to the local model for synthesis.
6. Report: The reporter assembles the analysis and source references into a Markdown report.

An audio digest can then be generated from the analysis through the ElevenLabs integration.

The relevant workflow code lives under backend/app/agent/ and backend/app/workflows/. The primary orchestration module calls the workflow stages in sequence, while the Temporal workflow and activity modules provide a separate path intended for durable background execution.

flowchart TD
    A[Research objective] --> B[Local AI planner]
    B --> C[Web search]
    C --> D[Extract page content]
    D --> E[Chunk and embed]
    E --> F[Qdrant retrieval]
    F --> G[Local model analysis]
    G --> H[Markdown report]
    H --> I[Optional audio digest]
    I --> J[Save artifacts]

The retrieval step is important because the analyst should work from collected evidence rather than relying exclusively on the model's existing knowledge. The report also records source URLs so that readers can inspect the material behind the findings.

Technical Architecture

Layer	Technology	Why it is used
Frontend	React, Vite, TypeScript	Task creation, monitoring, and results
Backend	Python, FastAPI	API endpoints and application services
Task persistence	SQLite, SQLAlchemy	Store task state and related records
Workflow modules	Python async workflow orchestration	Coordinate planning, research, indexing, analysis, and reporting
Local inference	Ollama with compatible Gemma or Qwen models	Generate plans and synthesize evidence locally
Web search	SerpApi	Retrieve current web search results
Web extraction	BeautifulSoup	Extract readable webpage content
Embeddings and retrieval	FastEmbed, Qdrant	Index text chunks and retrieve relevant passages
Document processing	pypdf, Markdown tooling	Extract and process supported documents
Workflow durability	Temporal integration	Provide a path for durable workflow execution
Observability	Sentry SDK integration	Capture configured telemetry and execution metadata
Audio digest	ElevenLabs	Convert the research summary into speech

The stack is deliberately modular. The local model communicates through an Ollama client, source collection is separated from extraction, and retrieval is isolated behind vector-store tooling.

That separation makes it easier to debug a failed search independently of a model-inference problem. It also makes future changes to the model or retrieval implementation less disruptive.

The presence of an integration in the repository does not, by itself, mean that every deployment has it enabled. Services such as SerpApi, ElevenLabs, Sentry, and Temporal require the relevant configuration and runtime dependencies.

How I Used Open-Source AI

The local-model component is central to Autonomiq. The backend's OllamaClient communicates with Ollama's generation endpoint, and the planner and analyst use that client to generate plans and synthesize retrieved evidence.

The configuration supports compatible Gemma and Qwen model names. For this project, Gemma through Ollama is the intended open-weight model path.

This approach gives the application control over the model runtime and makes it possible to perform the core language-model inference locally, without requiring a proprietary cloud LLM API for every planning or analysis step.

Open innovation also makes the system easier to experiment with. A developer can change the configured model, inspect the workflow, modify the prompts, or replace a tool without rebuilding the entire application around one hosted AI provider.

There are tradeoffs. Local inference consumes the user's own CPU, memory, and possibly GPU resources. Smaller models can produce weaker summaries, and performance depends on the model, quantization, and hardware. Live search and external speech synthesis also introduce network dependencies.

Consideration	Local model through Ollama	Hosted LLM API
Model inference	Runs on the configured local runtime	Runs on a provider's infrastructure
Data control	Prompts can remain local during inference	Prompts are sent to the selected provider
Cost model	Local hardware and electricity	Usually usage-based or subscription-based
Hardware	Limited by local resources	Uses provider-side compute
Model choice	Depends on locally available compatible models	Depends on the provider's offerings

The important distinction is not that local AI is always better. It is that the user gets a meaningful choice about where inference happens.

Real Example

A useful task for Autonomiq is a research request such as:

Research ten useful open-weight AI models, compare their capabilities and hardware requirements, and generate a report.

The intended processing path is to create a plan, search for relevant pages, extract available content, index the collected evidence, analyze retrieved passages with the local model, and save the final Markdown report. If configured, the workflow can also generate an audio digest.

The current interface also displays a task called "Verification Test" as completed, with six sources processed and two artifacts listed: report.md and digest.mp3. This is the state shown in the application interface, not a claim that I independently benchmarked the research quality or verified every citation.

A second use case is document research. A user can supply supported documents, have their text extracted and indexed, and use retrieval to provide relevant passages for subsequent analysis. This is useful when the information already exists in a collection of PDFs or notes.

A third use case is listening to the final summary instead of reading the entire report. The audio digest turns the report into a speech artifact, although its availability depends on the audio service being configured and the generation step succeeding.

What Makes It Different

Most AI research tools focus on the answer. Autonomiq models the process. Its workflow separates planning, searching, extracting, indexing, analysis, and reporting, making each stage easier to inspect.

Most chat interfaces assume the user remains present. Autonomiq separates task execution from the browser. The background-execution design is intended to let users leave the interface while the worker continues.

Many research workflows depend on hosted language models. Autonomiq supports local inference. The Ollama integration lets compatible open-weight models handle planning and synthesis on the user's machine.

A summary without evidence is difficult to verify. Autonomiq preserves source references. The indexer attaches source metadata to chunks, and the report includes source URLs and excerpts where available.

A report does not have to mean another screen session. The optional audio digest gives users another way to consume the result after the research task finishes.

These are architectural and product-design distinctions, not claims that every feature has been validated under every runtime configuration.

Build Process

I organized the implementation into phases so that the application could develop from a backend foundation into an end-to-end research workspace.

First, I established the project structure, environment configuration, API layer, database models, and request and response schemas. The task, step, source, and artifact entities provide the foundation for tracking research work.

Next, I implemented document parsing, file management, text chunking, and the Qdrant vector-store integration. These components provide the retrieval layer used by the research analyst.

I then built the workflow modules for planning, web search, extraction, indexing, analysis, and report generation. The local Ollama client keeps model communication separate from the individual stages.

After that, I added the Temporal workflow and activity modules, Sentry tracing support, and the ElevenLabs audio-digest integration. Finally, I built the React interface around task creation, Away Mode, task monitoring, and generated results.

The repository's progress.md, task_plan.md, and findings.md document the development process and decisions.

One important implementation decision was to keep the stages modular instead of placing the entire research pipeline in a single large function. Another was to make the local model runtime configurable rather than hardwiring a single model throughout the application.

Challenges and Lessons

1. Separating live search from content extraction. Search results provide candidate URLs and snippets, but snippets are not equivalent to full page content. The extractor attempts to retrieve page content separately. A failed extraction should remain distinguishable from a successful one.

2. Grounding analysis in retrieved material. The indexer connects chunks to source metadata before retrieval. This creates a path for evidence-backed analysis, but source attribution alone does not prove that every generated claim is correct.

3. Handling local inference failures. Ollama can be unavailable or unable to load the selected model. The application needs to distinguish model-runtime failure from an ordinary empty research result, rather than presenting both as successful analysis.

4. Making long-running work understandable. A task-oriented interface needs more than a spinner. Status, execution stages, errors, and artifacts help users understand what happened without reading backend logs.

5. Keeping the integrations honest. A configured integration is not the same as a successfully completed operation. Optional services need explicit availability and error states, and a task should not be presented as fully successful when a required stage fails.

Limitations

Autonomiq is an evolving project, and several limitations are important to state clearly.

• Search fallback behavior: The current researcher module includes fallback source records when live search returns no sources. These records are placeholders, not verified search results. They must be clearly marked or removed before treating every generated report as evidence-grounded.
• Extraction quality: Some websites may block automated access, return incomplete content, or provide pages that cannot be parsed reliably. Search snippets may remain insufficient for detailed analysis.
• Model availability: Local inference requires a compatible model runtime and sufficient hardware. The application does not make every model suitable for every machine.
• Fallback analysis: The analyst contains fallback behavior when model generation fails. Such output should be clearly labeled as fallback output rather than presented as equivalent to a successful model-generated synthesis.
• Workflow durability: Temporal workflow and activity modules exist, but the presence of those modules alone does not establish that crash recovery and retry behavior have been verified end to end.
• External services: Live search and audio synthesis depend on their respective service configurations. Local model inference does not make the entire application fully offline.
• Validation: I am not publishing performance or accuracy numbers because I do not have independently verified measurements for this write-up.

These are useful areas for continued development because a trustworthy research agent must make failures and evidence quality visible, not hide them behind a polished report.

Future Improvements

The next improvements I would prioritize are:

1. Evidence quality controls: Remove unverified placeholder sources from successful research results, clearly mark missing evidence, and validate that cited URLs correspond to retrieved material.
2. Durable execution testing: Verify actual worker interruption, restart, retry, cancellation, and task recovery behavior with integration tests.
3. Improved report exports: Add a structured PDF export with readable headings, source links, page numbers, and consistent typography.
4. Better model and resource management: Detect available models, provide clearer hardware guidance, and surface inference errors in the interface.
5. More transparent execution telemetry: Connect the task timeline to real stage events and expose meaningful latency, retry, and failure information.

I would prioritize source integrity and workflow recovery before adding more tools. A research agent should be able to explain what it did, which sources it used, and where its process failed.

Run It

The repository documents a local development setup using Python, Node.js, Ollama, and optional external integrations.

Clone the repository:

git clone https://github.com/TejasRawool186/Autonomiq.git
cd Autonomiq

Create the environment configuration:

cp .env.example .env

Configure the local model and any external services you intend to use. Install the backend requirements:

python -m venv .venv

Activate the environment, then run:

pip install -r backend/requirements.txt
python scripts/run_backend.py

In a second terminal, start the frontend:

cd frontend
npm install
npm run dev

Open http://localhost:5173. The backend API documentation is available at http://localhost:8000/docs when the backend is running with the documented local configuration.

For local inference, install Ollama and pull a model compatible with the configured model name. Live research and audio generation require the relevant API credentials. Check the repository's current setup instructions before running the optional workflow integrations.

Required project details

• Project: Autonomiq
• Repository: https://github.com/TejasRawool186/Autonomiq
• Challenge: Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
• Model runtime: Ollama
• Intended open-weight model path: Gemma
• Search integration: SerpApi
• Audio integration: ElevenLabs
• Agent tracing integration: Sentry, when configured

No dataset is required for the basic research workflow. The system collects sources for each research objective.

My Agent Session

I have not included an agent-session embed because I do not have a verified public DevRelay or other agent-session URL to share. The repository contains project planning and progress documents that describe the implementation phases.

Prize Categories

The integrations most directly represented in the code are:

• Best Use of Gemma: The local inference path uses Ollama with compatible Gemma model configurations.
• Best Use of SerpApi: The researcher calls SerpApi to retrieve web search results.
• Best Use of ElevenLabs: The audio-digest workflow calls the ElevenLabs integration to generate speech from the research summary.

Sentry tracing support is also present in the code, but I would only enter the Sentry category after verifying that the relevant execution spans are recorded and visible in a real run.

I am not claiming the Render, Temporal, or any other partner category solely because a configuration file or dependency exists. Those integrations need meaningful, verified execution before they should be presented as a completed partner-category entry.

Final Takeaway

Building Autonomiq made me think about AI productivity differently. The objective is not to maximize the time someone spends interacting with a model, but to reduce the supervision needed to complete useful work. Local inference gives users more control over where their documents and prompts are processed, while source attribution and execution visibility provide a foundation for trust. The next step is to make evidence handling and durable execution as reliable as the user experience is intended to be.