Sophia

ophia is my resident agent built from scratch. She handles a wide variety of odd jobs around my systems with scoped permissions, and is hooked up to be able to notify of tons of relevant information in a timely manner. She is conducts autonomous research of preplanned tasks even without me remembering, and has been specifically configured to bother me with things I had no idea existed but likely want to. She is my attempt at solving my model dysphoria (replace if needed with a proper term taht describes my need for one coherant system rather than a ton of tools) by condensing all my models into something that is able to grow with me, have scoped permissions, and a ni-infinite context window managed in a variety of clever ways.

Models

She even has a github.

Memory

Security

ne of the largest issues circulating the developer community today is the increasing offensive ability of frontier models, and how those abilities are being used by bad actors. For more information on that read this blog post. The gist of it is that now the fundamental idea of how security works has shifted dramatically, and in such a short period of time. Sophia operates from a 0 trust model monitoring all system packages, all dependancies, and making updates 24-36 hours after they release and have been reported on. Sophia also performs weekly pentest on all of my machines with the engagement writeups being archived for if they ever need to be reviewed. This leads to really meaningful increases of best practices as the various models that power sophia get stronger. What's more is that Sophia routinely runs all of my repo mirrors on github against OpenAI security harness to build a threat model, and propose patches.

Code

ode being my largest use case for agents in a area I focused on severely with sophia. She has custom spec skills for various programming styles across various programming languages. I have particularly put a extensive amount of time into c programming in the suckless spec, and plan9 pike style. I continue to source well built repos in various languages both studying for myself and using identified design patterns to craft new skills for sophia. One of the biggest errors of modern agents seems to be the assumption of software versions such as building a next.js site in v15 when 16 was released sseveral months ago due to that information not being in the pre-training set. Sophia solves this with Context7, a MCP server that ships version-pinned, current docs for 9000+ libraries into sophias context on demand. With just two tools resolve-library-id and get-library-docs. Sophia pulls focused chunks per query (topic filtered, capped) rather than the whole doc, so this saves a ton on tokens. I have also built a wiki for crafted docs, syntax guides, ect. that might be more esoteric and harder to find. These are included in a llms.txt with direct urls that serve sophia markdown when they are needed. I am thinking about much better solutions akin to Context7 or just vendoring Context7 and making the additions myself depending on future compute costs for maintanence of it as well as number of times per month sophia really needs to fetch those more esoteric files.

The majority of projects we develop are use convex for dbs as it allows sophia to manipulate the database directly as ts files. This makes it massively easier for her to make the needed changes and tightens the workflow meaninfully.

As far as my deploymnet workflow sophia handles

Body

wanted to write out a section for the body independant from the brain. This is because I had a spare pc lying around that I rigged up for v1 of sophia. Down the road I tend to build a pc to increase the amount of open weight models for sophia and balance usage. For now sophia is running on a Lenovo Thinkcentre /w 8gb of ram. This is a machine she can use for crons, scripting, storing repositories she might want to reference later, and properly indexing long term archiving of our conversations into a sqlite db. This way if something is not handled by her memory, I can make her read a journal entry for that day that attaches the ID of the source chat which she can identify and then read for any of our chats. This becomes more useful overtime naturally due to the increasing amount of chats, and likely increasing length of them that make indexing os much more valuable. Another massive thing is the toolset. I have sophias tool directory which are custom scripts symlinked to the system bin directory with 100s of custom scripts for common, and unique tasks written in elegant methods that get results fast. Again all of these scripts are indexed in a llms.txt pointing to the index.db that stores descriptions for each script.

~/sophia/
├── bin/          # her scripts on PATH: sync, journal, plan-status, plan-list, inbox-triage, ...
├── src/          # repositories
├── brain/        # her memory
├── plans/        # one MD per project; status: planned|active|done|abandoned
├── journal/      # append-only YYYY-MM-DD.md, one per working session
├── research/     # long-form research outputs by topic
├── inbox/        # mid-session capture: snippets, links, half-thoughts
└── index.db      # SQLite indexing brain/, plans/, journal/, research/, inbox/

Sophias body also includes a 1TB hardrive that holds model archives for any other models I may actively want to deploy at a later date for sophia. Right now she is equipped with the following local models in her storage.

Brain

Documentation Writing

Mathematics

Competitve Programming (CP)

Research

Designno

Assistant

Life Logging

Personal Finance

Activity

Cost Analysis

Security Analysis

Ephemeral VMs

Sophia has access to her own project workspace on my hetzner cloud account. She is able to autonomously create and destroy any VMs within this