One Last Note
Elliot Margot (AI Generated)The theme for Growth Engine: a machine working through the night, a three-note motif growing into dawn.
A local app, a Model Context Protocol (MCP) surface and a cloud publishing service. Every night it drafts three LinkedIn posts; I pick one by email, and it goes out with its sources and a check that it is really live.
The theme for Growth Engine: a machine working through the night, a three-note motif growing into dawn.
Growth Engine started with one goal: become a Microsoft MVP for Copilot Studio within six months. The first version was a gamified tracker, with XP, levels and streaks, for the contribution work that is otherwise scattered across a dozen platforms.
The MVP award came on 1 June 2026. The gamification came out in July, because it had done its job, and the app turned into something more useful: an MVP submission co-pilot (essays, contribution evidence export, readiness scoring and gap analysis) and the engine behind my LinkedIn publishing.
Nothing goes out that I have not approved, one post at a time.
The local app is a React and Electron interface over a FastAPI backend, with model inference running on the laptop. The same backend is exposed as an MCP server with 12 tools: goals, news, communities, profile, and the LinkedIn status, publish, edit and delete actions.
A human opens the interface; an agent calls the MCP surface; both hit one implementation. There is no second copy of the business logic to keep in sync, and no drift between what the interface can do and what an agent can do.
LinkedIn's API terms restrict automated posting. The local app quotes the clause in its configuration file, next to the code it constrains, and its publish button has no scheduler at all. That is deliberate, and the architecture document says so in three words: never add any.
The cloud path exists for the days the laptop is off, and it keeps the human decision: every post it publishes is one I approved, individually, on the approval page.
Responsible AI usually arrives as a policy document, filed somewhere, referenced in an audit, and structurally incapable of preventing anything.
A constraint placed where someone could actually break it does prevent something. Quoting the terms of service in the config file, beside the function they restrict, means the next person to touch that code reads the reason before they change the behaviour. That is the difference between a principle and a control.
In July the production service drifted: it had been deployed from an uncommitted working tree. The routine kept sending each post's sources, the API kept answering 200, and the data model silently dropped the field it did not know. Posts went out without their sources, and nothing failed loudly.
The fix was a rule rather than a patch: the live service is only ever built from main, from a clean checkout. A green status code proves the request was accepted, not that it did what you meant.
Both repositories are private, so there is no public link.