One Operating Loop Across Foxxkit, Bowerbird and Toucan Ops

Evidence label: KNIC build note — owned-system implementation
System status reviewed: August 2026

KNIC operates three separate systems because marketing content, business context and executable work need different ownership rules.

• Foxxkit owns front-of-house operations: websites, pages, forms, social drafts and the shared contact/consent layer.
• Bowerbird owns the organisation registry, curated context packs and a signed event log. It resolves identifiers across systems but does not claim ownership of their operational records.
• Toucan Ops owns goals, projects, tasks, approvals and agent-run records. It turns an authorised goal into bounded work.

The separation makes the write path more visible. An agent cannot quietly turn a piece of context into an external action without crossing an explicit system boundary.

The operating loop

1. A goal is created in Toucan Ops with a measurable target.
2. The planner assembles a bounded project and tasks, grounded in a Bowerbird context pack.
3. A worker selects only tasks that are ready under the venture's operating policy.
4. The executor may use a restricted set of Foxxkit tools for reads and draft creation.
5. An evaluator classifies the result as done, blocked or needing approval.
6. Sending, publishing, deleting or activating spend remains a human decision surfaced through Toucan's approval flow.
7. Signed events return to Bowerbird so context can be invalidated and the cross-system history reconstructed.

Controls that are operating now

• venture-scoped identifiers and site resolution;
• a curated context service with source and freshness metadata;
• HMAC-verified event ingestion from both Toucan and Foxxkit;
• idempotent event storage and cache invalidation;
• a safe tool allowlist for the executor;
• human approval before publish, send, delete or spend;
• recorded agent runs with steps, cost and error state; and
• an ad-spend gate that requires explicit human confirmation and enforces a site-level cap.

The connected platform has been exercised against the live services: Toucan node and document resolution, Foxxkit contact resolution, context assembly, and signed event round trips. The implementation record includes the migration of 271 delivery nodes across six spaces and a live Bowerbird service with context and resolution endpoints.

Those numbers describe KNIC's own operating system. They are not client scale or a client outcome.

Current limitations, stated plainly

The executor's Foxxkit MCP connection still uses an application-level admin credential. Venture scope is enforced in the Toucan client, but a separately scoped Foxxkit credential remains a hardening item.

Fully unattended promotion of backlog work is opt-in. By default, the worker executes only work an operator has marked ready.

Bowerbird's three-way context-quality comparison still requires a human judgement step. The system can assemble cited context; a person still decides whether the result is materially better than generic or website-only context.

Why this is implementation evidence

The interesting part is not that three applications can call one another. It is that each application has a narrow responsibility, external actions cross visible gates, failures have a state, and the system records enough evidence for a person to decide what happens next.

That is the same implementation discipline KNIC applies to a client workflow: name the source of truth, separate recommendation from authority, route exceptions, log the action and be candid about the remaining risk.

See the AI Workflow Diagnostic or bring KNIC one expensive workflow.