SYNTHESIS began with the idea of building my own JARVIS-like personal assistant.
The vision included natural conversation, awareness of context, memory, useful tools, controlled autonomy, and an identity that made the system feel coherent rather than assembled from disconnected features.
That vision still exists.
The current system is much smaller.
At this checkpoint, SYNTHESIS has working architectural foundations, several successful tests, and a clearer development direction. It does not yet behave like the complete assistant I imagine.
This is where it actually stands.
What exists today
SYNTHESIS is currently a Python project built around separate layers for models, tools, permissions, execution, context, reasoning, memory, perception, and interface work.
Not every layer is complete.
Some are working foundations. Some remain mostly structural spaces for later development.
The implemented and tested pieces currently include:
- A common model interface
- A predictable mock model for testing
- Initial local-model connectivity
- A standard structure for tools
- A registry of available tools
- Low-, medium-, and high-risk classifications
- Permission decisions and confirmation gates
- A tool executor
- Basic result verification
- Structured execution results
- Collection of approved system context
- Tests covering parts of the reasoning and action pipeline
These pieces do not form a finished assistant.
They form the foundation on which one can be built.
The model layer is intentionally replaceable
The project began with a base model adapter.
Its purpose is to prevent the rest of SYNTHESIS from depending completely on one model or provider. Different models may eventually vary in speed, cost, privacy, reasoning ability, and hardware requirements.
The first tests used a mock adapter.
The mock model was not intelligent. It returned predictable output so the rest of the system could be tested without introducing model uncertainty.
Initial connectivity with a local model also worked.
That confirmed that SYNTHESIS could communicate with a real language model running locally, but connectivity alone does not create dependable reasoning.
The model still needs to interpret natural language, produce valid structured requests, understand tool results, recover from mistakes, and continue conversations coherently.
Those behaviours are not complete merely because a model responded.
The tool foundation works
SYNTHESIS can define tools using a shared structure.
Each tool describes what it does, what information it accepts, how risky it is, how it executes, and how its result should be verified.
Tools can be registered and retrieved by name. The system can list what is available and reject tools it does not recognise.
This creates an intentional boundary around capability.
A model cannot make an action real simply by inventing its name. The surrounding application determines which abilities exist and how they may be used.
The current tools are still narrow and primarily useful for proving the system.
SYNTHESIS does not yet possess the broad collection of dependable everyday utilities required for the assistant I want.
Permission decisions work at a basic level
The permission manager can treat actions differently according to risk.
Low-risk actions can execute automatically.
Medium-risk actions follow the configured policy.
High-risk actions require explicit confirmation.
A test demonstrated this distinction successfully.
A harmless tool ran, returned its result, and passed verification. A deliberately high-risk test action stopped at the security gate, requested permission, and remained blocked when permission was denied.
This is one of the clearest successful behaviours in the project.
It is also still an early version.
Real risk depends on the action’s target, arguments, scope, context, reversibility, and relationship with other actions.
The current permission model establishes the principle.
Later development must make the judgment more contextual without making it unpredictable.
Execution and verification are connected
The executor links tool discovery, permission decisions, confirmation, execution, verification, and reporting.
That means SYNTHESIS has a basic path from a requested action to an observed result.
The path can distinguish among success, failure, an unknown tool, failed verification, and denial by the user.
This matters because the assistant should not treat every attempted action as completed.
The verification layer remains basic. Each real capability will require evidence appropriate to the action being performed.
Still, the architecture now expects verification rather than treating it as an optional improvement.
That expectation is already part of the system’s definition.
SYNTHESIS can assemble system context
The context builder can gather a structured snapshot of relevant computer information.
It has been tested with basic operating-system information, resource usage, available memory, process counts, and selected process observations. It can place those facts beside the current request and conversation context.
This allows reasoning to be grounded in actual observations rather than invented assumptions.
But this is not yet complete perception.
Reading system statistics does not mean SYNTHESIS fully understands the computer. It cannot yet interpret every screen, application, event, or changing situation reliably.
The context builder also needs stronger selection.
The system should gather information because the current task requires it—not because collecting everything is technically possible.
Context improves the assistant only when it remains relevant, current, and appropriately limited.
Reasoning exists as a pipeline, not yet as dependable judgment
Parts of the reasoning pipeline can receive structured observations and carry information through the system.
The architectural path is becoming clearer:
The user provides an instruction.
Relevant context is assembled.
The model interprets the request.
A tool may be selected.
Permissions are evaluated.
The action may execute.
The outcome is observed and verified.
A response is produced.
Individual sections of this path have passed tests.
The complete experience is not yet dependable enough to describe as a finished conversational agent.
A real conversation involves ambiguity, follow-up questions, corrections, changing context, incomplete tasks, and memory across multiple interactions.
That persistent conversational loop is one of the next major milestones.
The interface is still the terminal
SYNTHESIS currently reveals most of its progress through terminal output and test scripts.
That is useful during development.
The terminal exposes tool registration, permission decisions, system observations, confirmation requests, failures, and execution results without hiding them behind an interface.
It is not where I expect the assistant to remain.
Eventually, I want to communicate naturally rather than shape every interaction around tests and commands. Voice, shortcuts, background operation, and a dedicated interface are all possible parts of that experience.
They are not the current priority.
The foundation should become useful before the presentation becomes cinematic.
What SYNTHESIS cannot honestly claim yet
SYNTHESIS is not currently a fully autonomous personal assistant.
It cannot safely do anything I ask.
It does not possess complete visual understanding of my computer.
It does not yet have dependable long-term memory.
It cannot independently manage complicated goals across every application.
It does not have a finished voice or graphical interface.
Its early permission system does not solve every form of risk.
Its verification is not equally strong for every possible action.
Its current tests demonstrate architecture, not daily reliability.
These limitations do not make the project meaningless.
Pretending they do not exist would.
The purpose of this checkpoint is to separate progress from presentation.
What comes next
The immediate priority is a dependable conversational core.
SYNTHESIS needs to accept ordinary language, preserve the relevant conversation state, select appropriate actions, incorporate observations, and respond naturally across multiple turns.
After that, the practical toolset needs to grow carefully.
Useful everyday capabilities matter more than impressive demonstrations. Each tool should have clear permissions, failure handling, and verification before the system relies on it.
Perception and memory can then become richer without turning into uncontrolled collection.
The interaction layer—voice, shortcuts, background operation, and a proper interface—should make the underlying system easier to use once that system deserves the presentation.
More advanced capabilities belong later, after the simpler ones work repeatedly.
The project will remain laptop-first. Larger computing resources or paid services should solve demonstrated limitations, not substitute for careful architecture.
The vision has become more realistic, not smaller
At the beginning, I imagined SYNTHESIS as one complete intelligence.
Now I see it as a system of boundaries.
The model reasons but does not authorise itself.
Tools act but only through defined interfaces.
Permissions decide whether action is allowed.
Verification checks whether the intended outcome occurred.
Context grounds the reasoning but should remain limited.
Memory creates continuity but must be controllable.
The interface communicates capability without exaggerating it.
Breaking the assistant into these pieces has made the project look less magical.
It has also made it possible to build.
This is a checkpoint
SYNTHESIS is somewhere between an idea and an assistant.
The important foundations are no longer imaginary. Models, tools, permissions, execution, verification, and context have working representations and successful tests.
The useful daily experience still needs to be created.
That is the next phase.
Future articles will no longer retell the origin. They will document actual milestones: what was attempted, what broke, what changed, what was rejected, and what the system can genuinely do afterward.
The original question was whether I could build something resembling my own JARVIS.
The better question now is more demanding:
Can each new capability make SYNTHESIS more useful without making it less understandable, less controllable, or less honest?
That is what the next version has to prove.