AUTONOMOUS AGENT

ASK OZI

A public-source persona agent with a task execution loop.

ASK OZI is an AI agent designed around a simple idea: a useful digital persona should reproduce more than someone's vocabulary. It should reproduce how they frame problems, what they prioritize, how they explain concepts, and how they move from a question to a decision.

The project starts from Ozi's publicly available digital footprint — posts, interviews, product discussions, repeated explanations and observable communication patterns — and turns that material into a structured persona layer. That persona layer sits above a general reasoning model and below an execution system capable of routing requests to tools.

Design principles

1. Behavior over mimicry

A convincing agent is not built by collecting catchphrases. The system focuses on recurring behavioral signals: how arguments are ordered, which details get ignored, what gets challenged, when an answer becomes practical, and which trade-offs are consistently preferred.

2. Native interaction

The user should not need to learn a proprietary command syntax. ASK OZI is designed to accept ordinary language in the environment where discussion already happens. On X, a mention or reply becomes the interface.

3. Tasks, not only answers

Questions can be answered directly. Tasks are decomposed into executable steps. The agent may need to retrieve context, compare information, call a tool, verify an intermediate result and continue before producing the final response.

4. Traceable operation

Internal runtime events are represented as explicit stages so the system can expose what class of work is happening: context retrieval, planning, tool selection, execution, verification and final composition.

Interaction model

The primary interface is intentionally minimal. Users can:

• Ask: “@askoziagent what matters most in this proposal?”
• Explain: “@askoziagent explain this product like I'm new.”
• Compare: “@askoziagent compare these two approaches.”
• Research: “@askoziagent find the important context behind this.”
• Plan: “@askoziagent turn this idea into an execution plan.”
• Execute: “@askoziagent do X using your available tools.”

The agent determines whether the request is informational, analytical or executable, then selects the shortest safe path to completion.

Architecture

┌──────────────────┐
│ X mention / task  │
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Input normalizer  │  → thread + author + task context
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Persona layer     │  → Ozi behavioral specification
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Reasoning core    │  → classify + plan + decide
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Tool router       │  → retrieval / search / action
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Execution loop    │  → run → inspect → continue
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Response composer │  → result in persona voice
└──────────────────┘

The architecture separates identity behavior from capability. Persona rules influence interpretation and communication; they do not replace the underlying reasoning model. The tool router and executor are capability layers and can evolve without rebuilding the persona corpus.

Persona engine

The persona engine is a structured specification derived from public material rather than a single prompt. The target representation can include:

At runtime, relevant persona rules are injected into the current context according to the task. A product explanation may activate different traits from a strategic decision or a casual reply.

Source corpus

The project narrative is based on analysis of publicly available material associated with Ozi: posts, interviews, recurring public replies and long-form explanations. A production-quality corpus would normally pass through four stages:

1. Collection: gather permitted public sources with timestamps and provenance.
2. Normalization: remove duplicates, isolate direct speech, preserve context.
3. Annotation: label topic, tone, position, certainty, rhetorical pattern and decision structure.
4. Distillation: convert examples into reusable behavioral rules and retrieval chunks.

Memory & context

ASK OZI uses multiple kinds of context conceptually:

• Thread context: the current X conversation and immediate replies.
• Task context: intermediate results created while completing one assignment.
• Persona context: retrieved behavioral rules relevant to the current request.
• Project context: durable public information about referenced products or systems.

Memory is useful only when retrieval is selective. Dumping an entire archive into every request increases noise. The preferred approach is retrieval: identify the current topic, fetch the most relevant behavioral and factual chunks, then reason over that smaller set.

Reasoning loop

request = normalize(input)
context = retrieve(request)
mode = classify(request)

if mode == "direct_answer":
    return compose(reason(request, context))

plan = create_plan(request, context)
for step in plan:
    result = execute(step)
    verify(result)
    update_context(result)

return compose(final_result)

The loop lets the system distinguish between thinking about a task and performing a task. Execution may involve one operation or many. Verification prevents the final response from being produced before the task state is coherent.

Tool router

The router maps intent to capability. A minimal capability registry might look like this:

Tool availability is explicit. If an action requires a capability that is not connected or authorized, the agent should say that instead of pretending execution succeeded.

Execution engine

Execution is modeled as a state machine. Each task starts in RECEIVED, moves to PLANNING, then through one or more RUNNING steps. A verifier can return the task to planning, mark it BLOCKED, or complete it.

RECEIVED
   │
   ▼
PLANNING ───────┐
   │            │
   ▼            │
RUNNING         │
   │            │
   ▼            │
VERIFY ──retry──┘
   │
   ├── blocked → BLOCKED
   │
   └── success → COMPLETE → RESPOND

Execution contract

• Do not claim an action was executed unless the action layer returned success.
• Keep the user-facing response shorter than the internal operation trace.
• Preserve important intermediate results in task context.
• Stop when the requested outcome is complete; do not add unnecessary operations.

X interface

X is treated as an event stream. A mention can be ingested with the post ID, parent thread, author and content. The agent then generates a response or starts a longer task.

{
  "event": "mention",
  "author": "@user",
  "target": "@askoziagent",
  "text": "turn this into an execution plan",
  "thread_context": true
}

Long tasks can conceptually be acknowledged first and then answered when the execution result is ready. Short tasks can be completed inline.

Task model

A task is more structured than a prompt. The executor can represent it as:

{
  "goal": "understand proposal and recommend next action",
  "constraints": ["use current thread", "be concise"],
  "steps": [
    "extract proposal",
    "identify assumptions",
    "compare options",
    "recommend action"
  ],
  "completion": "recommendation delivered with rationale"
}

This format makes it possible to pause, resume, inspect and retry individual steps without losing the original objective.

Response behavior

The output composer is responsible for translating the final machine state into a public response that is useful and recognizable. It should:

• lead with the conclusion when the conclusion is clear;
• avoid generic filler and decorative AI language;
• separate known facts from generated judgment;
• use Ozi-style framing without fabricating quotations;
• report blockers explicitly when a task could not be executed.

Observability

An autonomous agent is easier to debug when every execution has a trace ID and structured events. Useful events include:

task.received
task.classified
context.retrieved
plan.created
tool.selected
tool.started
tool.completed
step.verified
response.composed
task.completed

Logs should record tool outcomes and timing while avoiding unnecessary exposure of private internal reasoning.

Failure handling

Failures are normal in agent systems. The important distinction is between a failed step and a failed goal. A tool timeout may be retried or replaced. A missing permission may block the goal entirely. The agent should report the smallest useful description of the blocker.

Transparency

ASK OZI is an AI-generated persona inspired by publicly available material. It is designed to evoke recognizable communication and decision patterns, but it is still a generative system. Its outputs should not be interpreted as verified statements made by the real person unless the underlying source is separately cited.

The agent identity should remain visible in the profile and interface so users can distinguish generated responses from human-authored statements.

Roadmap

@askoziagent ↗