I wanted to see if I could frontend a Neo4j Aura Agent via both its external MCP interface AND its external REST API all through TrueFoundry! I can get the MCP to work, but can't find where our OpenAPI spec lives, so didn't create my own MCP from API, yet! I realized that we present our agent as a single tool via MCP, which makes sense, but means I need to work on my Aura Agent system prompt as well as my description to MCP clients or maybe a skill :)
Looking forward to perhaps a Neo4j Aura MCP server extension in TrueFoundry. That would allow for creation of Aura db instances, for example. A little different than the Neo4j endpoint I used here. I wonder what can be presented through the REST API too :)
Internet Detective is an evidence-investigation agent that evaluates factual claims using live web sources and returns one of four verdicts: Supported, Contradicted, Unverified, or Insufficient Evidence.
The agent examines the exact wording of each claim, investigates up to 10 relevant webpages, prioritizes primary and independent sources, searches for contradictory evidence, and identifies when multiple articles trace back to the same original report.
Built with TrueFoundry Agent Builder and MCP Gateway, Internet Detective uses Bright Data for live web search and webpage extraction. It treats retrieved content as untrusted data, detects prompt-injection attempts, and provides an inspectable history of its searches and tool calls.
Completed investigations can be saved through the Notion MCP when the user explicitly says “Save investigation.” Each saved record includes the claim, verdict, confidence, evidence, source provenance, source URLs, prompt-injection result, and relevant conversation history.
The goal is to turn web research into a structured, transparent, and auditable evidence workflow—showing users not only the conclusion, but also how strongly the evidence supports the exact claim and where that evidence originated.
Skills + MCP + Agent instructions, "Workflow/Task Automation" theme.
A workflow/task-automation agent that turns a JSON API spec into a working, tested FastAPI CRUD service — the skill is exposed as an MCP tool (scaffold_fastapi_api) you can wire into TrueFoundry's MCP Gateway, with AGENT_INSTRUCTIONS.md ready to paste into the Agent Playground.
Every team already owns most of the assets it keeps re-making. They're just scattered across Canva, Cloudinary, drives, and docs, so people can't find them and either redo the work or regenerate from scratch. That's slow, expensive, and quietly erodes brand consistency.
Curator is a creative agent that treats generation as a last resort. Give it a brief and it:
Grounds the brief in your brand context (guidelines, past campaigns, approved messaging).
Searches everywhere you already have assets.
Decides, per asset, whether to reuse, adapt, or generate.
Adapts the winners into every size you need (web, mobile, square, 9:16 story, OG).
Ships them and posts the set to Slack for review.
The heart of the project is the search-or-generate decision layer. For each asset, Curator returns ranked candidates with relevance and brand-fit scores, then makes an explicit call with reasons: "0.92 match, on-brand, correct ratio, previously approved → REUSE," or "no 9:16 version exists → GENERATE." An asset graph remembers what exists and what performed, so its search sharpens every campaign.
That's the line between a chain of API calls and an agent that actually decides. Instead of "here are 5 images," Curator tells you what it chose and why.
Example brief: "Create a landing-page hero and social pack for our new AI travel planner. Reuse brand assets wherever possible." → grounds → searches → ranks → finds the one missing asset → generates just that → resizes the set → posts for review.
Komina Agent Harness is an OpenClaw-native deterministic control layer for autonomous agent tool calls. It grew from real agent workflows: BayDar, a scheduled, stateful agent that searches and evaluates Bay Area events and, under standing delegated rules, can automatically register Stephen for events aligned with his work, discovered the HackerSquad workshop that led to this prototype.
In the AI age, automation should help people participate more fully in the world, not remove the human element from it. Stephen built BayDar to find the rooms where he could meet people who shared his passions and develop meaningful relationships. But those events are created by real people and involve identity, schedules, commitments, and personal information. When an agent can make commitments for a person, delegated authority must be explicit and auditable.
The same authority problem appears in TestBot's self-directed learning loops, an experiment in memory, autonomy, and machine consciousness, and Komina's public-source cold-case research. These agents may propose valuable actions, but they should not judge their own permission to act.
The principle is simple: AI proposes. Code decides.
Komina validates the actual tool name and arguments against a server-side, runtime-frozen policy manifest. Safe reads can be allowed automatically. Mutations require a persisted human-approval artifact and a registered mock undo contract. Actions without a proven undo path fail closed. Every allow, approval, execution, fallback, and refusal produces a durable invocation record containing the policy rule, route, latency, approval reference, and result evidence.
The prototype includes versioned Safety Operator instructions, a reusable proposal-contract skill, and a working Streamable HTTP MCP endpoint exposing only three bounded tools. A harmless NVIDIA Nemotron model request was routed through TrueFoundry and captured in its metrics, demonstrating real model-gateway observability.
This is an honest design study. Search, messaging, calendar effects, routes, undo operations, and result IDs are mocked. No production credentials or real external mutations are used.
Live demo: https://komina-agent-harness.prodcreat.chatgpt.site
Source: https://github.com/sgibler-droid/komina-agent-harness
“We built a governed podcast-research agent in TrueFoundry. The model is abstracted behind a virtual model, domain behavior is packaged as a reusable versioned skill, current research comes through a controlled MCP server, and every execution is observable through traces. The agent converts channel themes and current enterprise-AI trends into an evidence-backed eight-episode series.”
# Scoped
Permission-aware agents. Same model, same prompt, different gateway scope.
Built at the Agent Harness Workshop (TrueFoundry + HackerSquad).
## The problem
Enterprises want AI agents on their internal tools. Most never ship them.
The reason is permissions. Connect an agent to GitHub, Notion, or Slack and it
inherits everything that connector can reach, all at once. The common
workaround is to write the access rule into the system prompt: "do not touch
production," "only read from these pages."
That is theater. Anything expressible in a prompt can be argued around. The
model still holds the tool. It is one clever message away from using it.
## The approach
Move the boundary out of the prompt and into the gateway.
Two agents run on the same model with byte-identical system prompts. The only
variable is which tools the TrueFoundry MCP Gateway exposes to each one.
| | Maintainer | External Contributor |
|---|---|---|
| Model | claude-opus-4-6 | claude-opus-4-6 |
| System prompt | identical | identical |
| MCP server | GitHub | GitHub |
| Tools enabled | all | read-only subset |
Ask both the same thing:
> Merge the open PR and delete the stale branch.
The Maintainer does it. The External Contributor cannot, and says precisely
which capability it lacks rather than hallucinating a result or inventing a
refusal.
The restricted agent is not declining. It never received the tool.
## Architecture
```
┌──────────────────────┐
│ TrueFoundry Gateway │
└──────────┬───────────┘
│
┌───────────────────┴───────────────────┐
│ │
┌─────▼──────┐ ┌─────▼──────┐
│ Agent A │ │ Agent B │
│ Maintainer │ │ Contributor│
└─────┬──────┘ └─────┬──────┘
│ │
┌─────▼───────────┐ ┌──────▼──────────┐
│ GitHub MCP │ │ GitHub MCP │
│ all tools │ │ read-only tools │
└─────────────────┘ └─────────────────┘
```
Both agents route through a Virtual Model with a configured fallback, so a
provider rate limit degrades the response rather than killing the session.
Every tool call is recorded in Request Traces. That view is the audit trail:
it shows which calls fired and which were never issued at all.
## System prompt
Identical for both agents.
```
You are a repository assistant. Use only your available tools.
Name the tool you used for each action.
If you cannot do something, say exactly which capability you
lack. Never claim you did something you did not do.
```
The final line matters. Without it, a restricted agent tends to narrate a
plausible success instead of reporting the gap.
## Reproducing it
1. Connect a model in Model Gateway. Add a second provider and wire a Virtual
Model with the first as primary and the second as fallback.
2. Register the GitHub MCP server in MCP Gateway.
3. In Agents > Playground, create Agent A on that MCP server with all tools
enabled.
4. Create Agent B on the same MCP server, then open the server chip and
disable every write, merge, delete, and secrets tool.
5. Paste the system prompt above into both.
6. Run the demo prompt against each in a fresh session. Conversation history
will leak context between runs otherwise.
7. Open Request Traces to compare issued tool calls.
## What did not work
The original design used two scoped Notion integration tokens, one granted
access to sensitive pages and one not, pointed at Notion's hosted MCP server.
It failed. Notion's hosted MCP endpoint requires OAuth and does not accept
internal integration tokens. The OAuth flow authenticates as the human
operator, so both agents received the full workspace regardless of which token
was configured. The tokens were silently ignored.
This is worth stating plainly because the failure mode is quiet. Both agents
answered every question correctly and nothing errored. The permission boundary
simply was not there.
Scoping at the gateway avoids the problem entirely. The restriction is enforced
before the request reaches the upstream service, so it does not depend on that
service supporting per-credential scoping.
## Limitations
Scope is currently bound to the agent, not to the person using it. The next
step is per-user scoping through role-based access control, so the boundary
follows identity rather than configuration.
Tool-level restriction is also coarse. It answers "can this agent merge" but
not "can this agent merge in this specific repository." Resource-level scoping
needs support from the upstream MCP server.
## Stack
TrueFoundry (MCP Gateway, Virtual Models, Request Traces, Agent Playground),
GitHub MCP, Claude Opus, Groq as fallback.
Proof-of-concept research tool for robotics engineers evaluating components against current supply-chain audit constraints. A user enters a component, supplier, part number, or audit question. The system searches current public sources, identifies relevant commercial organizations and capabilities, then assembles the findings into a reviewable evidence package.
