FOVEA

Inspiration

AI agents often work with very long conversations, source files, logs, tool outputs, and error messages. Compressing this context can reduce token usage, but aggressive compression can also remove the exact detail the agent needs.

A missing file path, function name, line number, or exception can completely change the next action taken by the agent.

We realized that the real problem was not simply how to compress context. The bigger question was deciding what should be compressed, how aggressively it should be compressed, and what must always remain clear.

That idea led us to FOVEA.

The name comes from the part of the eye that keeps the point of focus sharp while processing the surrounding area at a lower resolution. FOVEA applies the same idea to AI context. It keeps critical information sharp and compresses less important context more aggressively.

What it does

FOVEA is an adaptive context control layer built for Paritok.

Instead of applying the same compression level to every part of a conversation, FOVEA studies each segment and decides whether it should remain raw or be compressed using Paritok at L0, L1, L2, or L3.

It looks at signals such as:

How recent the segment is
How relevant it is to the current task
Whether it contains source code
Whether it contains file paths or identifiers
Whether it contains errors or tracebacks
Whether it has already been referenced
Whether it is repetitive or no longer important

Important content such as system instructions and the active user request stays protected. Recent errors and identifier-heavy code are compressed carefully. Old logs and repetitive tool output can be compressed more aggressively.

After compression, FOVEA validates the result. It checks whether important paths, symbols, errors, line numbers, commands, and references survived.

If a compressed result is unsafe, FOVEA automatically retries with a safer level. It can move from L3 to L2, then L1, L0, stock Paritok, and finally raw content.

This means FOVEA does not accept a smaller context just because it looks efficient. The compressed output must also remain useful and safe.

How we built it

We built FOVEA as a complete context decision and validation pipeline around Paritok.

The system has five main parts.

The first part is the feature extractor. It studies every context segment and calculates signals such as recency, semantic relevance, identifier density, code density, error signals, dependency importance, and repetition.

The second part is the policy engine. It uses those signals along with strict safety rules to select RAW, L0, L1, L2, or L3.

The third part is the Paritok adapter. It sends the content, segment type, and selected compression level to the Paritok compression pipeline.

The fourth part is the safety validator. It verifies that important technical details survived the compression.

The fifth part is the fallback engine. When validation fails, it retries the segment using a safer level until a valid output is found.

We also built an interactive dashboard that explains every decision. It shows the original context, selected level, final accepted level, feature scores, safety rules, fallback path, token usage, and identifier survival.

For evaluation, we compare three versions of the same context:

Raw context with no compression
Stock Paritok compression
FOVEA with adaptive compression and validation

We keep simulator results clearly separated from real Paritok results. Every benchmark records the backend, model, tokenizer, policy version, dataset version, and configuration used for the run.

Challenges we ran into

One of the biggest challenges was balancing token reduction with information safety.

It was easy to create a policy that compressed more text. The difficult part was proving that the smaller context still contained everything the agent needed.

Our first simulator produced impressive token savings, but many compressed outputs failed our own validator. Important identifiers and technical details were sometimes lost.

Instead of hiding those failures or weakening the validator, we changed the architecture. We introduced progressive fallback and started measuring the final accepted output instead of the first compression attempt.

Another challenge was separating simulation from real model performance. The early interface used a local compression simulator, which was useful for testing the policy flow but could not represent real Paritok performance.

We redesigned the system so simulator mode and real Paritok mode are clearly separated. The project never presents simulated numbers as real benchmark evidence.

We also found several difficult integration issues involving cache isolation, compression levels, duplicate segment IDs, backend failures, invalid embeddings, dataset leakage, and fair token counting.

Each of these problems required stronger tests and clearer provenance.

Accomplishments that we're proud of

We are proud that FOVEA became more than a compression demo.

It is now an explainable safety and control layer for context compression.

Some of our main accomplishments include:

Supporting RAW and Paritok levels L0 through L3
Protecting system instructions and active user requests
Detecting real tracebacks and unresolved errors
Preserving important paths, symbols, line numbers, and error names
Adding progressive fallback when compression becomes unsafe
Keeping stock Paritok behavior available as a safe fallback
Building cache isolation across levels, models, backends, and policy versions
Creating session-isolated evaluation splits
Comparing raw context, stock Paritok, and FOVEA fairly
Building an interactive decision inspector
Adding a Judge Mode that explains the complete workflow
Creating reproducible JSON, JSONL, CSV, and HTML reports
Adding automated tests for the policy, validator, adapter, benchmark, and interface
Preparing an upstream-ready integration path for Paritok

Most importantly, FOVEA refuses to claim a performance win unless it reduces tokens while matching or improving stock Paritok on critical information survival and downstream task quality.

What we learned

We learned that context compression is not only a token optimization problem.

It is a decision problem.

Two segments with the same length can have completely different value. A large old log may be safe to compress heavily, while one short traceback may contain the exact line needed to solve the task.

We also learned that average quality scores can hide dangerous failures. Losing one critical file path or exception name can matter more than preserving hundreds of ordinary words.

This pushed us to focus on exact identifier survival, task success, worst-case sessions, and fallback behavior instead of relying only on text similarity.

Another major lesson was that honest evaluation makes the project stronger. When early results failed our own quality checks, we treated that as useful evidence instead of trying to make the numbers look better.

The result is a system that values reliable agent behavior more than impressive but unsafe compression percentages.

What's next for FOVEA

Our next goal is to turn FOVEA into a native adaptive policy layer that can be used directly inside Paritok and other agent frameworks.

We plan to expand the evaluation dataset with more real coding sessions, languages, repositories, tool outputs, and debugging tasks.

We also want to improve semantic relevance using stronger local embedding models and explore constrained learned policies that can adapt to different agents without breaking safety rules.

Future versions of FOVEA could support: