Outside Agent: a local-first prompt that gets the screen out of the way

This is a draft submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass. It is deliberately marked as a draft: the CLI and its tests are complete, but I have not yet run a locally installed model or published the source repository.

What I Built

Outside Agent is a small command-line tool that turns a few constraints into one outdoor micro-adventure: a broad area, available time, energy level, and an interest such as birds, plants, or light.

The point is to make the screen the shortest part of the experience. The model makes a compact plan; the person then leaves the device behind and completes the activity outside.

The tool intentionally asks only for a broad area. It does not collect an address, track location, check weather, invent trail conditions, or make claims about opening hours or accessibility. Every generated plan tells the user to choose a public, legal, familiar place and verify local conditions themselves.

Demo

The implemented CLI accepts a local Ollama model and a small input set:

python3 outside_agent.py \
  --area "a nearby public park" \
  --minutes 35 \
  --energy low \
  --interest birds

It sends one request to http://127.0.0.1:11434/api/generate with streaming disabled, then prints the model's Markdown plan.

The project has automated tests for the user-context prompt, its safety contract, and the local Ollama request shape:

Ran 3 tests in 0.000s
OK

I have not run a downloaded model in this environment yet, so I am not presenting a generated outdoor plan as a measured result. A real local-model transcript or video demo is the next required validation before this draft becomes a contest submission.

Code

The initial source is a standard-library Python CLI with a small unit-test suite:

• outside_agent.py — prompt contract, local Ollama request, CLI arguments, and explicit error handling.
• tests/test_outside_agent.py — no-network tests for user-context handling, the safety instructions, and the /api/generate request.
• README.md — local setup, run command, test command, privacy boundary, and current status.

Before publication, I will make this source available in a public repository and add the repository URL here. I will not imply that a private local folder is a public code release.

How I Built It

The open component is the model runtime: Outside Agent uses Ollama to call a locally installed open-weight model. The default model name is gemma3:4b, but the command accepts any installed model name through --model.

The model is constrained by a system prompt that requires four sections:

1. Mission — one practical outdoor activity.
2. What to bring — only ordinary, low-risk items.
3. Screen-off cue — a clear point when planning ends and the device can stay away.
4. Adaptation — a bounded fallback if the user's chosen place or conditions are unsuitable.

The prompt also forbids local factual claims and medical, emergency, wildlife-handling, or navigation advice. Those are deliberately human decisions, not model outputs.

Why Does Open Innovation Matter?

For this project, local inference is not a decorative implementation detail. It makes the tool usable without a cloud API key and lets a person choose the model that runs on their own machine. The user controls the model, the runtime, and the small amount of context that leaves the command line.

That is a better fit for a tool whose purpose is to reduce time on a screen: it should not require a new account, an analytics pipeline, or continuous location collection in order to suggest a short walk, a bird-listening loop, or a plant-observation prompt.

Open-weight models also make the prompt and safety boundary inspectable. If a community finds a better way to make the planner more useful or more cautious, the implementation is small enough to understand and change.

Validation Still Needed

This draft is not a claim that the model has been evaluated. Before submitting it to the challenge, I will:

1. Run the CLI against an actually installed local open-weight model.
2. Save a real terminal transcript or video demo.
3. Publish the source repository.
4. Re-read the final post against the challenge rules and publish only if the code, demo, and article all match the evidence.

Comments

[baumgaerben]

Local-first agent architectures are exactly where I've been pushing my side projects lately — the latency drop alone when you're not round-tripping to an API for every tool call changes the whole feedback loop. Curious how you're handling context window pressure when the agent runs multi-step tasks locally; have you hit a point where summarization or hierarchical memory becomes necessary, or is the current prompt scope staying tight enough? Also, any friction with local model tool-calling reliability compared to the hosted equivalents? — found it via LabAgent, site: labagent .tech

[Alex Shev]

Context pressure is usually a reason to preserve task artifacts, not to keep an ever-growing transcript: keep the current goal, constraints, and an explicit tool/result ledger in the live prompt, then summarize completed branches with links or paths to the original evidence. Hierarchical memory only earns its complexity when retrieval can cite the underlying artifact and the agent can tell a summary from a source of truth. For tool calls, I would treat local and hosted models the same operationally: narrow schemas, validate arguments and results, and make every side-effecting step idempotent or approval-gated. That turns occasional tool-call mistakes into bounded failures rather than silent task drift. Which tool class has been least reliable in your projects—filesystem edits, browser actions, or structured API calls?