Skip to main content

Roadmap

OWL's development priorities, guided by the philosophy: Get out of the model's way.

Now​

Currently in progress or next to implement.

UI Polish​

Small improvements for better feedback:

  • Elapsed time indicator - Show response duration
  • Enhanced edit feedback - Display lines added/removed with diff preview
  • Grouped file reads - Collapse consecutive reads into summary

Knowledge Relevance Threshold​

Filter low-relevance RAG results to reduce noise:

# Only include results above 70% relevance
results = knowledge_store.search(query, min_relevance=0.7)

Next​

Planned for near-term implementation.

Better Project Detection​

Smarter context from project config files:

FileInformation Extracted
package.jsonDependencies, scripts, project type
pyproject.tomlPython deps, build system
pom.xml / build.gradleJava project details
README.mdProject description

Conversation Export/Import​

Backup and migrate sessions:

/export session.json     # Export current session
/import session.json     # Import session

Auto-Remember​

Model can write to memory.md when it learns something important (with user approval), inspired by Molt.bot.

Future​

Considering for later. May change based on model improvements.

Permission Patterns​

Granular allow/deny by command pattern:

permissions:
  allow:
    - "git add *"
    - "git commit *"
  ask:
    - "git push *"
  deny:
    - "rm -rf *"

Find past conversations by content:

/search "authentication bug"

MCP Support​

Model Context Protocol for standardized tool interfaces and external integrations.

Plugin System​

Lightweight extensions without bloating core:

  • Custom tools
  • Output formatters
  • Integration hooks

Team Features​

  • Shared settings files
  • Common knowledge bases
  • Synchronized soul evolution (optional)

Decided Against​

Features we considered but rejected to keep OWL simple.

Runtime Model Switching​

Why rejected: Users can change model in ~/.owl/config.yaml. Runtime switching adds complexity for marginal benefit.

Multi-Model Orchestration​

Why rejected: Routing logic is complex, error-prone, and the benefits diminish as models improve. Single good model is simpler.

Philosophy Check​

Before adding anything, we ask:

  • Can we delete code instead?
  • Does this get in the model's way?
  • Is this the simplest solution?
  • Would this survive a model upgrade?

Features that don't earn their complexity get cut.

Want to contribute? Check GitHub Issues for current priorities.