Feature Request: Support for alternative agentic frontends — building a neurosymbolic panel-based client

Context

I'm building PanLL, a reference implementation of the eNSAID specification (Environment for NeSy-Agentic Integrated Development) — an open spec for neurosymbolic development environments where human developers and AI agents collaborate through a three-panel architecture:

• Panel-L (Symbolic) — constraints, formal guarantees, active rules
• Panel-N (Neural) — AI reasoning, proof search, agent thinking
• Panel-W (World) — verified results, tool output, system state

The stack is Elixir (agent orchestration, BEAM supervision), Rust (tool execution via Tauri), and ReScript (panel UI). It currently has 52 panels and 22 cartridges.

The idea

I'd like to build Claude's agentic capabilities as a native PanLL client — not a fork or copy of Claude Code, but a new frontend that calls the Anthropic API directly, using the public Messages API and tool-use protocol.

The motivation is visibility and resilience:

• Context budget as a visible gauge, not a hidden threshold — Panel-L constraints enforce resource limits at the UI level, preventing the context blowouts that crash heavy sessions
• Agent reasoning visible in Panel-N — you can see why Claude is about to take an action before it executes
• Subagents as detachable panels — parallel agents are literally visible in separate panels, each with their own lifecycle
• Elixir supervision trees for crash isolation — individual tool calls can fail without taking down the session (five-nines resilience from the BEAM)
• Tool output filtering at the panel layer — Panel-W shows the full output to the human but sends only a digest to the API, keeping context lean

What I'm asking

1. Is building an alternative agentic client on the Anthropic API something Anthropic actively supports, beyond what the Agent SDK already enables?
2. Are there any architectural guidelines or constraints I should be aware of for tool-use protocol compatibility?
3. Would there be interest in this as a community-driven reference for non-CLI agentic interfaces?

I'm a paying API customer and this would use standard Anthropic API authentication and billing. No proprietary Claude Code source would be used — this is a clean-room implementation in different languages.

If anyone at Anthropic would like to discuss this further, you're very welcome to reach out — happy to walk through the eNSAID spec and how the panel architecture maps to agentic workflows.