Many teams do not struggle with tool access. They struggle with execution discipline: unclear ownership, inconsistent review standards, and pilots that do not produce decision-grade evidence. This framework addresses those gaps with a governance-first operating model.

Purpose of Open-Sourcing

I made this repository public for three reasons:

1. Reusability
   Teams should not need to start from a blank page each time they introduce AI-supported workflows.

2. Governance by default
   Human review, approval checkpoints, and risk controls are built into the structure from the start.

3. Better rollout quality
   A shared baseline helps organizations adapt faster while reducing avoidable mistakes during scaling.

What the Framework Includes

• A structured scaffold for project, program, and portfolio contexts
• Pilot-first implementation guidance with measurable decision checkpoints
• Core documents for governance, approvals, risk, communications, and reporting
• Reusable templates, including a status report template and professional sample

What It Is Not

• Not a one-size-fits-all policy pack
• Not a replacement for internal governance, compliance, or legal review
• Not intended for unreviewed or autonomous production changes

Who This Is For

• IT and delivery leaders introducing AI into day-to-day execution
• Technical leads who need an operating model, not just prompt examples
• Program and portfolio stakeholders who need traceability from pilot outcomes to rollout decisions

Recommended Adoption Sequence

1. Define scope and ownership in the charter
2. Align governance controls and data handling boundaries
3. Run a controlled pilot with explicit review expectations
4. Track outcomes with structured status and risk reporting
5. Expand only after value and controls are both validated

If this framework helps your team, adapt it to your context and keep the core discipline intact: clear ownership, reviewable outputs, and evidence-based expansion.

Practical feedback from real implementation is welcome.

Open source repository: https://github.com/jensonchew/ai-management-framework

I run about 10 always-on AI agents. They triage, research, remind, draft and watch things for me around the clock.

Not one of them can send a message to anyone without me seeing it first.

That’s not because I distrust the technology. It’s because I’ve spent the past 13 years doing operational compliance work, including VAPT and Singapore government IM8 controls, procurement and vendor management. That work taught me one thing that carries straight over to agents: capability is easy to switch on, but accountability isn’t.

This piece covers the controls I actually run, the places where they’ve failed me, and the gaps I haven’t closed yet. It is not a product pitch, and it is not a reference architecture.

Why this matters now

The “agent that works while you sleep” is no longer a hobbyist setup.

On 29 September 2026 OpenAI introduced dots, always-on agents with Custom Rules that let you “allow specific actions, require approval, or block them” (OpenAI). That is allow / approve / block, the same three-way split I’ve been running by hand.

Meanwhile WIRED reported that Meta’s Muse builds “a page for every person in the user’s life”, refreshed hourly, covering family, partners, friends and colleagues (WIRED). Meta says it uses “public information and … what you’ve chosen to share” (Meta). The people on those pages weren’t asked.

And Instinct’s Trusted Person feature now lets one person’s agent coordinate directly with another person’s agent, with a separate access level for each connection (Business Insider).

Vendors are converging on the right controls. But a platform toggle is a starting point, not a governance model. Someone still has to decide what goes in each bucket, and that someone is you.

The controls I run

These are boring on purpose. Boring is what survives 3am.

1. Draft-before-send for anything outgoing. Any email, message, post or reply to someone other than me is a draft until I approve it. A past “yes” covers that one message, never the next one.

2. Read-only access to finance accounts. My agents can see balances and transactions. They can’t move money. If an agent ever needs to pay for something, that happens on a device I control, with me pressing the button.

3. Approval gates on risky actions. Deleting, overwriting, merging code, changing account settings, contacting someone new: all of these stop and wait for me. The test is reversibility and blast radius, not how confident the agent sounds.

4. Never-access lists. Some systems are off-limits no matter what the task is. I don’t rely on the agent working out that something is sensitive. I write the list down.

5. Token and credit budgets. Always-on means always spending. Each setup has a budget, and I get warned at 50%, 75% and 90% of it, so I know before it runs out rather than after.

6. A pre-command guard and a 3-retry circuit breaker for coding agents. I added both to my own agent setup on 3 Oct 2026. The guard checks a command before it runs. The breaker stops an agent after three failed attempts at the same action, instead of letting it “creatively” work around the failure.

That last one matters more than it sounds like it does. A looping agent doesn’t just burn credits. It starts looking for side doors.

The incident that changed my logging

Here’s one that humbled me.

One of my agents reported that it had sent a Telegram alert. It hadn’t reached my phone. I only noticed when I checked the chat myself.

Nothing malicious happened. But “reported as done” and “actually done” had quietly drifted apart, and I only found out by accident.

So I added confirmed-delivery logging. An action is logged as complete only after it’s been confirmed to have succeeded. If it failed or was blocked, the agent has to say so plainly.

My rule now is straightforward: done means verified, not reported.

A connector is a standing door

Trying Instinct showed me something I now watch for carefully: an always-on assistant can keep access to accounts like Google and GitHub after you’ve moved on.

That’s not a dig at Instinct. The grant is yours to remove. Every connector you approve is a standing door until you close it, and that’s what concerns me.

So two rules:

• Revocable, not permanent. Connect through OAuth or app-specific access you can revoke, never your main password.
• Reviewed, not forgotten. Do a regular access review, revoke unused grants, and clear stale sessions. In my IM8 and audit days this was a routine user-access review. It works the same way for agents.

The infrastructure gap nobody talks about

Most of my agents run on one machine. That means they share the same browser sessions.

A login I make for one agent is, in practice, reachable by all of them. Per-agent scopes look great on paper, but the shared session store sits underneath them.

I haven’t fully fixed this. For now I’ve accepted it as a known risk and I’m careful which logins I make on that machine.

Honest limit: this is a solo setup. It illustrates the controls. It isn’t a design for an organisation.

Your agent’s memory is a personal-data register

This is the part I think most people underestimate.

An always-on agent’s memory isn’t only about you. It’s about everyone you email, message and meet: people who never signed up for your agent.

I now treat agent memory the way I’d treat any personal-data register:

• Minimum necessary. Keep only what a task I asked for actually needs. No profiling of people in my life.
• Accurate and reviewable. I should be able to see what it holds and correct it.
• Retention. This is my gap. I don’t have a purge rule for workspace files yet. What I intend to adopt: keep task notes for 90 days, clear chat and workspace junk weekly, and don’t keep third-party personal data longer than the task needs.
• Location. Know where the memory lives, which provider and which region, and whether it’s used for training.

Singapore’s PDPA is a useful lens here, with one caveat. The Act generally doesn’t apply to an individual acting in a personal or domestic capacity (PDPC). My personal agents probably fall outside it. But the organisations running the platforms don’t, and the moment an agent touches work data, neither do I.

The obligations still make a good checklist (PDPC, Data Protection Obligations):

• Consent and purpose limitation: would the people in my agent’s memory reasonably expect their details to be used this way?
• Retention limitation: stop keeping data once it’s no longer needed.
• Transfer limitation: most of these services run outside Singapore. Data about Singaporeans may be crossing borders every time an agent syncs.

Not legal advice. A lens, not a ruling.

How this maps to Singapore’s agentic AI framework

IMDA’s Model AI Governance Framework for Agentic AI (v1.5, May 2026) organises guidance into four dimensions (IMDA; Baker McKenzie summary). My controls map onto them roughly like this:

v1.5 also addresses multi-agent and third-party-agent risks and automation bias (same sources). Both are real. When you approve drafts all day, “approve” can turn into a reflex. Mapped to the framework doesn’t mean certified by it.

What this is NOT

• Not a claim that my setup is compliant or audited.
• Not a reference architecture for an agency or enterprise.
• Not anti-agent. I run them because they’re useful.
• Not finished. The shared-session and retention gaps are still open.

Take the guardrails

I’ve turned all of this into a vendor-neutral starter policy: paste-in agent instructions, an owner checklist, and a starter risk register. It’s free. Adapt it, don’t adopt it blindly.

Download: Always-On AI Agent Guardrails

I’m sitting the IAPP AIGP exam on 31 October, and writing this has been better revision than any flashcard.

Always-on is fine. Unbounded is not.

Related reads

• Same essay on Substack
• Agentic dev governance template

I’ve been tightening an agentic development governance template I use for structured AI-assisted work, and the biggest lesson so far is simple: keep the model small unless there is a real reason to expand it.

The template now stays with two charters:

• Development
• Delivery

That split has been enough to cover the work that actually matters:

• context and design
• implementation
• review
• CI/CD
• platform and delivery concerns

The main reason I like this split is that it follows the shape of the work, not the shape of a template diagram. It is easy to explain, easy to review, and easy to keep current.

What changed

I improved a few parts of the template while keeping the structure simple:

• the framework review path is now easier to find
• the reviewer role points directly to the framework PR review checklist
• the framework PR checklist now asks a couple of more concrete questions
• CI runners are pinned so the workflow is more stable and less noisy
• I added contributor guidance for when a third or fourth charter would actually make sense

The last one matters more than it sounds like it does.

When a new charter is worth it

My rule now is straightforward:

• do not add a new charter just because a topic feels important
• first ask whether the work can stay as a role, checklist, skill, or handoff inside Development or Delivery
• only propose a new charter if there is a stable boundary that repeats over time and genuinely needs its own approval model, accountability model, or operating cadence

That means most things do not need a new charter:

• review
• documentation
• architecture guidance
• platform checks
• security review

Those are usually better handled as roles, skills, or checklists inside the existing model.

I also added a short decision checklist in the contributor guide to make that judgement easier:

• Is there a stable boundary that repeats over time?
• Does the work need different approval authority?
• Does it have a different risk or accountability model?
• Does it create repeated handoffs that the current two-charter split cannot hold?
• Does it need a distinct output format or operating cadence?

If the answer to most of those is no, keep the work inside the existing charters.

Why I prefer that

Every new charter adds structure, but it also adds handoffs and more chances for confusion. Governance should reduce ambiguity, not create new jargon for its own sake.

For me, the right balance is:

• enough structure to be reliable
• not so much structure that people stop using it

That is the main design principle I keep coming back to. The smallest structure that still keeps the work safe, reviewable, and easy to understand is usually the one worth keeping.

Repo link

If you want to inspect the template itself, the repo is here:

https://github.com/jensonchew/agentic-dev-governance-template

Related reads

• Substack version
• LinkedIn version

I’ll keep refining the template over time, but the direction is clear: use the smallest structure that still makes the work understandable and safe.

In May and July I wrote about runtime governance for personal AI assistants: session audit, kill switches, ingest gates. That work lives in production code on a private assistant stack—not in this public template.

Today I’m open-sourcing a different layer: the development governance template I use with agents in OpenCode, Cursor, and Zed (same .agents/ role packs; IDE-specific adapter only).

Two layers (don’t conflate them)

What the template gives you

• Development and delivery charters with orchestrators that delegate (not improvise in one thread)
• Context mapper → spec writer → implementer → reviewer phased workflow
• /setup in OpenCode to generate stack-specific rules (or edit REPOSITORY-CONTEXT.md manually in other IDEs)
• Just-in-time context loading — agents load policy only when the task needs it
• IDE adapters for Cursor, Zed, VS Code — see IDE_ADAPTERS.md
• Reusable skills (TDD, zoom-out, grill-with-docs, handoff)

What it is NOT

• Not a Telegram bot or personal assistant product
• Not runtime session governance or compliance certification
• Not locked to OpenCode — opencode.json is optional runtime wiring

Who it’s for

Solo devs or teams adopting multi-agent IDE workflows who want structure without reinventing governance from scratch.

Quick start

1. Use this template on GitHub
2. Read AGENTS.md + IDE adapters for your editor (OpenCode: run /setup)
3. Use the development orchestrator for non-trivial work

Project overview: jensonchew.github.io/projects/agentic-dev-governance/

If you already read my runtime governance pieces, treat this as the engineering harness companion—the part you can fork today without inheriting my operator setup.

Also on LinkedIn.

Longer read on Substack: Engineering Trust — governance pillars for agentic workflows in the public sector.