Notice What Changed Without Watching Everything
A proposed context layer that notices useful changes from sources you approve and sends only the right signal to Zinley.
Abstract
Agents that work across calls, files, browsers, and long-running tasks need current state, but continuous collection creates noise and privacy risk. Zinley Sensor is a research architecture for converting events from approved sources into small, policy-scoped observations. A filtering layer decides whether an event should be ignored, attached to open work, shown to the owner, or used to resume an authorized task. The output feeds the private context of one Zinley. It does not create a separate observer identity on each device.
The Perception Gap
A task can become stale between one agent turn and the next. A build may finish, a call may end, a file may change, or a recipient may reply. If Zinley only learns about that change when the owner opens a chat and reports it, the owner remains the monitoring layer.
The goal is not unrestricted observation. The goal is bounded perception: receive an event from an approved source, extract the minimum useful state, and connect it to the existing person, Topic, rule, or commitment.
Figure 1. Events originate from sources the owner has approved. Policy and relevance filters run before a signal reaches Zinley or becomes durable context.
From Event to Useful Context
The proposed pipeline has five stages. Each stage can stop an observation before it reaches memory or triggers work.
No source is observed merely because the device is connected. Access begins with an explicit permission, remains scoped to the selected source, and can be revoked.
What Becomes Memory
An observation is not automatically saved. A build completion may matter only until the task closes. A client preference may belong in that person's relationship record. A promised follow-up may belong in the open work and commitment record. Storage should follow purpose, not collection convenience.
This distinction keeps device state from becoming a second, unstructured memory system. The same Zinley decides how an approved observation relates to the owner's existing people, work, and rules.
Figure 2. Only context with a defined purpose should persist. Other observations expire with the task or are discarded.
Examples
These scenarios explain the design direction. They are not published benchmark results or promises that every connected app supports the same event model.
A call ends
The approved call summary is linked to the caller's relationship record and current work thread. A promised follow-up appears in the owner's Brief.
A long task stalls
An approved runtime reports that output stopped. Zinley investigates within the task boundary or asks the owner before expanding scope.
A requested file changes
The allowed folder runtime reports a new version. Zinley updates the open task without scanning unrelated files.
A recipient replies
The reply is attached to the existing relationship and commitment, so the next action does not begin from a blank inbox.
Limits and Open Questions
Relevance filtering can fail in both directions. It can interrupt too often or miss an event that mattered. Source permissions do not by themselves make every derived inference appropriate to store or act on.
Evaluation should therefore measure false interruptions, missed actionable changes, excess retention, and actions stopped by authority checks. High-impact decisions still return to the owner.
Conclusion
Useful perception is not continuous access to everything. It is the ability to notice a relevant change within an approved scope and reconnect it to the same Zinley, relationship, task, and rule set.
The research challenge is to improve continuity without turning the owner's devices into a surveillance layer. Permission, reduction, purpose, retention, and authority must remain part of the perception pipeline.