In my first Spark post, Field Signal was already using my local model. The next step was rebuilding the content workflow around that API: researching a story, putting together a draft, checking sources, and moving it through review.
I want to spend my time building things, learning how they work, and writing about what happened. Field Signal is my brand. The agents should help with the repeated work around it, without turning agent management into another full-time job.
The model connection was one piece. This rebuild put a clearer workflow around it, with defined roles, a place to see the work, and a path back to me when something needs my review.
Giving the Spark a real job
The newsroom drafts and reviews articles through a private gateway to the Spark. It now selects GLM-5.3-Flash-EXL3. The configured local model were used during the earlier migration and review work. The new newsroom environment has no OpenAI or Anthropic model keys and no cloud text-model fallback.
That lets me rely less on cloud inference for this part of Field Signal. It does not remove the cost of hardware or the need for external sources and site hosting. It gives the text-model work a home on equipment I own.
It also gives me a useful way to learn. I can follow a request from a worker to the model and back into the story record. When it fails, there is a real workflow to investigate. Running a model becomes part of running an application.
Where everything runs
| Machine | What runs there | What it does for Field Signal |
|---|---|---|
| MS-A2 | Paperclip and newsroom coordination | Shows tasks and gives me a place to review personal articles. |
| Dell | VKS newsroom workers, private API, and ledger collector | Executes the work that moves stories through the pipeline. |
| Spark | The configured local model | Supplies local model responses. |
MS-A2 is the brain. Dell is the workhorse. Spark runs the models. A task appearing in Paperclip does not mean inference runs there. Paperclip shows the work; the Dell workers make the model requests.
VKS gives those workers a consistent place to run in my vSphere lab. I can inspect their containers, see completed jobs, and investigate failures. The detailed installation belongs in its own build log, because networking, Avi, and storage took more work than the diagram suggests.
Four roles with clear jobs
The newsroom became Editor, Reporter, Reviewer, and Publisher. Apollo and Argus were replaced. Fifteen older agent identities were paused with their history retained, and twenty older drafts stayed available for my review.
Editor coordinates story work. Reporter prepares drafts. Reviewer checks them and can request another pass. Publisher handles release when a story is allowed through.
Each role checks for work every minute and handles at most one story per run. These are scheduled workers, not four chatbot windows that must stay open. The private newsroom API connects the task view to the work.
Each story keeps a durable record. Claims and expiring leases coordinate which worker owns a task. Execution failures retry up to three times before becoming blocked. Source captures, model responses, draft versions, and review findings stay in private history.
That is what I want the agents to carry for me. A draft that needs work should go back with a reason. I should be able to see what happened without reconstructing the entire run myself.
What has actually made it through
Three stories completed the new publication path: a markets story, a Volkswagen ID.4 recall story, and a Ligue 1 rights story. Their live pages returned article content, and the story store marked them published. The sports story went through a revision before release.
Sports, cars, and markets each have a daily discovery pass for at most one new story per desk per UTC day. That is the current scope, not a claim that the newsroom should publish as much as possible.
My personal articles still need my approval. The agents can help prepare and check them, but I decide what goes out under my name. Newsletter and social delivery remain off.
These are early results. A few completed stories prove the path can work. They do not yet show how much time it saves over a month or how often I will need to step in.
Less management is the goal
Paperclip needed attention too. The synchronizer was repeatedly rewriting unchanged stories, and a missing database index slowed a comment request. Fixing both removed that repeated write activity and improved the measured requests. A task view needs to respond when I use it.
The models also need checks. Local inference does not automatically produce good writing or teach the model my tone. The current workflow uses separate source and editorial review passes with the configured model. Those passes are not independent model verification. Their conclusions still need supporting sources and human judgment.
The model route is private, authenticated, and certificate-verified. There is no public model endpoint for site visitors to use. The newsroom runs on one physical Dell, so that host remains a point of failure. Scheduled off-cluster backups and a continuing Avi licensing plan are still work to finish.
More room to build and learn
I rebuilt this so the repeated steps around content can take less of my attention. That is the goal I want to measure as the system runs, rather than call it solved after the first successful jobs.
The Spark supplies local inference. The Dell executes the newsroom work. MS-A2 keeps the coordination together. I can use the same setup to learn about models, containers, storage, and application behavior while it does something useful for Field Signal.
I still choose the subjects, do the experiments, and review my personal writing. The agents can help carry the logistics between an idea and a finished piece. That is where I want this to go.