Context gets scattered.
The useful detail is spread across documents, conversations and applications. Someone has to find it, reconcile it and explain it again.
SystemLens / Context → Decisions → Execution → Evidence
Put your agents to work.
See what happens next.
SystemLens is the software I’m building to coordinate AI agents around a person’s work: give them relevant context, define the task, control what they can do and keep the evidence of what happened.
For business owners carrying the context for their whole operation—and builders who want their agents to share that context and finish bounded work. I sell implementations and build custom applications around this foundation.
Working componentsFounder-operated implementationsIntegration in progress
This page includes recorded execution, interactive design previews and an explicit build list. Preview data is illustrative; customer systems are private.
The work is bigger
than one conversation.
A useful answer still needs context, an owner, permission to act and a way to check the result.
Handoffs lose the thread.
An agent’s draft is only one step. People and tools still need to know what is ready, what is blocked and what evidence counts as done.
Activity hides the bottleneck.
A busy agent or a full task board does not explain where work waits, repeats or fails. That is the process-intelligence question SystemLens is being built to answer.
One operating loop.
Clear responsibilities.
Architecture overview. Select a layer to see its role and the implementation boundary.
Integration depends on the source
Bring in the relevant work.
Connect only the sources needed for the chosen process. Preserve where information came from and distinguish imported material from accepted knowledge.
SystemLens is the broader context and coordination layer. StarNet is one agent execution and visualization surface. Stromalytix applies the foundation to scientific work; its lab hardware remains a separate development effort.
Open the task.
Inspect the result.
Actual recorded StarNet work from an isolated Biofab demo. Two sequential tasks produced saved reports.
16 seconds · silent · native footage at 2× speed with explanatory overlays. The review findings were added after the runs; they are not evidence of automatic scientific validation.
Input
Six model records.
The parameter agent was asked to review sources, estimates, units and applicability. The assay agent was asked to connect proposed equipment to biological readouts.
Output
Two saved drafts.
Each run wrote a report. The parameter run finished; the assay report was saved before a later note step was canceled.
Review
Claims still need checking.
Subsequent review rejected an unsupported literature-absence claim and a claim that proposed imaging hardware was already integrated.
Make the loop visible.
A place to see the task, its dependencies, the current handoff and the evidence behind each state.
Interactive design previewSynthetic exampleNo live agent connection
CaptureSource received
ContextInputs linked
DraftArtifact returned
ReviewDecision required
ActionGranted tool only
Evidence ↺Record the outcome
Example event 1 of 6
A request arrives.
Synthetic intake note: prepare a meeting follow-up. No real contact or customer data is loaded.
The operator loop visualizer has a separate branch implementation. Live source readers and production activation remain pending. This lightweight public preview explains the interaction; it does not expose that private operator application or dispatch work.
What has to be connected next?
Read-only owner APIs, correlated task and receipt IDs, source freshness, retained evidence during outages and verified operator permissions. Board state, transport acknowledgments and completed work must remain distinguishable.
Find where the work waits.
Process intelligence should connect events to a case, measure delays and rework, and help choose the next improvement.
Planned production dashboardSynthetic timing example
140 minTotal elapsed
120 minWaiting for review
86%Share spent waiting
Calculated using the same synthetic events as the CSV linked below. These are not customer results or measured savings.
Download sample event logMeasure the process before changing it.
Separate active work from waiting. Track which steps repeat, where approvals pause a case, whether sources were current and whether the intended result was actually achieved.
Historical event-log extraction tools exist. Continuous ingestion, customer-specific baselines, reliable case correlation and an integrated process-intelligence dashboard remain integration work.
The next proof is a replayable event trail from one real, consented workflow, with counts and timing checked against the source system.
Useful work needs
explicit control.
The design puts authority alongside context and execution. Each integration needs to demonstrate these boundaries.
Source-aware context
Keep sources, assumptions and unresolved conflicts with the proposed work. Treat incoming material as data to examine.
Permission before action
Define which tools a task may use and when a person must review it. A tool’s presence alone does not grant permission.
Evidence before “done”
Keep a returned artifact, a delivery receipt and an accepted outcome as separate states. A queue acknowledgment does not prove completion.
Limits you can verify
Check reversibility, credentials, usage accounting and stop controls in the actual integration. Configuration alone is not proof that a limit works.
Built, partial,
and next to connect.
Snapshot: September 26, 2026. These placeholders specify the missing proof and integration work.
Context and agent foundation
Working componentsShared knowledge retrieval and recorded file-producing agent tasks are exercised. Availability depends on the deployed connector and workflow.
Loop visualizer
Branch implementationOperator UI and observation-service code exist. Next: authorize and verify owner readers, activate the projection, and prove end-to-end refresh.
Process-intelligence dashboard
Integration placeholderExtraction tooling exists. Next: continuous case-linked events, measured wait/rework, checked baselines and a customer-facing view.
Next-action recommendations
PlannedNext: rank opportunities against real business goals, explain evidence and uncertainty, and test usefulness with an operator. General per-customer autonomous operation is not demonstrated.
Repeatable deployment
Workflow-specific workNext: verify installation, permissions, monitoring and recovery for each bounded workflow before offering it as a repeatable package.
Start with one
consequential process.
Implementation work begins with a specific recurring task, its sources and the evidence that would make the result useful.
- Choose the bottleneck.Identify the repeated handoff or decision that depends on you.
- Connect the context.Confirm source access, data boundaries and the tools allowed to act.
- Build and verify the loop.Inspect a real output, review the action and test the failure path.
- Operate and improve.Measure results and exceptions before expanding the workflow.
Scope, access and pricing are agreed for the implementation. The previews above do not connect to your accounts.