Add TypeScript agent authoring example with plugin-friendly setup#127
Open
smurching wants to merge 151 commits intodatabricks:mainfrom
Open
Add TypeScript agent authoring example with plugin-friendly setup#127smurching wants to merge 151 commits intodatabricks:mainfrom
smurching wants to merge 151 commits intodatabricks:mainfrom
Conversation
- Added 7 tools to /api/chat endpoint using AI SDK format: - Basic tools: calculator, weather, current_time - SQL tools: execute_sql_query, list_catalogs, list_schemas, list_tables - Updated serving endpoint to 'anthropic' in databricks.yml - Added LangChain dependencies for agent support - Created agent infrastructure (agent.ts, tools.ts, tracing.ts) - Created /api/agent/chat route (alternative endpoint) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Remove separate /api/agent/chat route (use chat.ts only) - Simplify tools to only get_current_time tool - Remove calculator, weather, and SQL tools (were contrived) - Clean up imports in index.ts Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Updated tools.ts to only export time tool (per PR feedback) - Added conversion logic in chat.ts to use agent tools with AI SDK - Identified issue: Databricks provider uses remote tool calling - Next: Convert LangChain agent streaming to AI SDK format Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Architecture:
- Client calls /api/chat (no changes to frontend)
- Backend runs LangChain agent with server-side tools
- Agent streams chunks converted to AI SDK UIMessageChunk format
- Tools defined server-side in agent/tools.ts
Implementation:
- Created getAgent() to lazily initialize and cache AgentExecutor
- Replaced streamText() with agent.stream()
- Convert LangChain streaming format to AI SDK format:
- Tool calls: { type: 'tool-call', toolName, args }
- Tool results: { type: 'tool-result', result }
- Text: { type: 'text-delta', delta }
- Finish: { type: 'finish', finishReason }
Current issue:
- Agent initializes with tools correctly
- Model receives proper input
- But model returns empty tool_calls array
- Need to investigate @databricks/langchainjs tool binding
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Found that @databricks/langchainjs doesn't specify useRemoteToolCalling when creating the Databricks provider, which defaults to true. This causes the AI SDK to mark tools as remote/provider-executed rather than sending them in the API request. Key findings: - node_modules/@databricks/langchainjs/dist/index.js:394 creates provider without useRemoteToolCalling parameter - @databricks/ai-sdk-provider defaults useRemoteToolCalling to true (per TypeScript defs at dist/index.d.mts:51) - When true, tools are marked as dynamic/providerExecuted, appropriate for Agent Bricks but not foundation model endpoints - Foundation models like databricks-claude-sonnet-4-5 need useRemoteToolCalling: false to receive tools in API requests Next steps: - File bug report with @databricks/langchainjs - Consider workaround: use AI SDK directly instead of LangChain - Or patch node_modules temporarily for testing Added test-direct-tools.ts to reproduce the issue. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fixed the tool calling issue by modifying @databricks/langchainjs to pass useRemoteToolCalling: false when creating the Databricks provider. This ensures tools are sent in API requests to foundation model endpoints. Changes: - Modified ~/databricks-ai-bridge/integrations/langchainjs/src/chat_models.ts to set useRemoteToolCalling: false in createProvider() - Updated server/package.json to use local langchainjs package via file: path - Added test-tools-fixed.ts to verify the fix The issue was that useRemoteToolCalling defaults to true, which tells the AI SDK that tools are handled remotely (like Agent Bricks). For foundation model endpoints, we need to pass tools as client-side tools, so it must be set to false. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added multiple test scripts to validate the useRemoteToolCalling fix:
- test-claude.ts: Tests with databricks-claude-sonnet-4-5 (SUCCESS ✅)
- test-fm.ts: Generic foundation model test
- test-anthropic.ts: Tests with anthropic endpoint
- Updated test-tools-fixed.ts to use environment variables
Test Results:
✅ databricks-claude-sonnet-4-5 successfully called get_current_time tool
✅ Tool received correct arguments: {"timezone": "Asia/Tokyo"}
✅ Tool executed and returned: "Friday, February 6, 2026 at 3:05:48 AM GMT+9"
✅ Fix confirmed working: useRemoteToolCalling: false enables tool calling
This validates that the fix in @databricks/langchainjs correctly passes
tools to foundation model endpoints.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Updated ports to avoid conflicts with other development servers: - Frontend (Vite): 3000 → 5000 - Backend (Express): 3001 → 5001 Changes: - client/vite.config.ts: Updated server port and proxy target - server/src/index.ts: Updated CORS origin for new frontend port Note: Server port is controlled via CHAT_APP_PORT env var (defaults to 5001 in dev). Frontend port is hardcoded in vite.config.ts. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Replaced agent.stream() with agent.streamEvents() to expose individual tool calls and results as separate events in the stream. This allows the UI to display tool execution in real-time. Key changes: - Use streamEvents() with version 'v2' for event-by-event streaming - Handle on_tool_start events → emit tool-call chunks - Handle on_tool_end events → emit tool-result chunks - Handle on_chat_model_stream events → emit text-delta chunks - Track tool call IDs with a Map to match start/end events - Convert LangChain event format to AI SDK UIMessageChunk format The streaming now emits: 1. tool-call events when agent decides to use a tool 2. tool-result events when tool execution completes 3. text-delta events for the final synthesized response Tested with get_current_time tool - all events stream correctly. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changed from custom 'tool-call'/'tool-result' chunk types to the standard AI SDK chunk types that the UI expects: - tool-input-start: Signals tool call began - tool-input-available: Provides tool input data - tool-output-available: Provides tool output/result This ensures the UI properly renders tool calls as 'dynamic-tool' parts which the message component displays with Tool/ToolHeader/ToolContent. The AI SDK's useChat hook converts these chunks into dynamic-tool parts with states: input-streaming → input-available → output-available. Tested with get_current_time tool - chunks stream correctly and UI should now render tool calls properly. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Previously, text-start was emitted at the beginning of the stream, causing all text content to render as a single text part ABOVE tool parts in the message. Now: - text-start is only emitted when we receive the first actual text content (on_chat_model_stream event) - This happens AFTER tool execution completes - Tool parts now render before the final text response Event order is now: 1. start, start-step 2. tool-input-start, tool-input-available, tool-output-available 3. text-start, text-delta (final response) 4. finish This matches the expected UX: show tool calls first, then show the agent's response about the tool results. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Investigated feasibility of exposing MLflow-compatible /invocations endpoint: Key findings: - MLflow has well-tested LangChain → Responses API conversion logic - AI SDK provider already converts Responses API → AI SDK chunks - All pieces exist to implement this architecture Benefits: - Standard MLflow-compatible interface for external clients - Reuses existing conversion logic on both ends - Cleaner architecture with standard interfaces Next steps documented in RESPONSES_API_INVESTIGATION.md Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Added Responses API endpoint that converts LangChain agent output to MLflow-compatible format, enabling external clients to consume the agent. Key components: 1. Conversion helpers (responses-api-helpers.ts) - Ported from MLflow's Python conversion logic - createTextOutputItem, createFunctionCallItem, etc. - langchainEventsToResponsesStream() - main converter 2. /invocations endpoint (routes/invocations.ts) - Accepts Responses API request format - Runs LangChain agent with streamEvents() - Converts events to Responses API SSE stream - Supports both streaming and non-streaming modes 3. Export getAgent() from chat.ts for reuse Tested with curl - returns proper Responses API format: - response.output_item.done (function_call) - response.output_item.done (function_call_output) - response.output_text.delta - response.completed Next: Update frontend to use AI SDK provider to query this endpoint Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Successfully implemented and tested MLflow-compatible /invocations endpoint. Key findings: - ✅ Endpoint works perfectly with curl (external clients) - ✅ Proper Responses API format (function_call, text deltas) - ✅ Server-side invocation produces compatible output - ✅ Dual endpoint strategy: /invocations for external, /api/chat for UI Recommendation: Keep both endpoints for maximum flexibility. Frontend can be migrated to use provider later if desired. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…g UI Implements npm workspace structure that matches Python template DX while providing TypeScript benefits. Key features: 1. Setup script (scripts/setup-ui.sh) - Auto-fetches UI if not present - Checks sibling directory first (monorepo) - Falls back to GitHub clone (standalone) 2. Workspace configuration - agent-langchain-ts is the main entry point - UI becomes workspace dependency - Type safety across agent/UI - Single npm install 3. Developer workflow - cd agent-langchain-ts - npm run dev (UI auto-fetches!) - Modify agent.ts - Deploy one app Benefits: ✅ Matches Python DX (single directory, auto-fetch) ✅ TypeScript benefits (workspaces, type safety) ✅ Works standalone AND in monorepo ✅ Single deploy artifact Documentation: - agent-langchain-ts/ARCHITECTURE.md - Developer guide - WORKSPACE_ARCHITECTURE.md - Architecture overview Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add MLflow-compatible /invocations endpoint to agent-langchain-ts - Implement Responses API format with streaming support - Simplify agent server to focus on /invocations only - Configure npm workspaces for agent + UI integration - Add concurrently to start both servers with single command - Fix e2e-chatbot-app-next bugs (package name, vite proxy port) - Add comprehensive architecture and requirements documentation - Enable independent development of agent and UI templates Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Revert all unnecessary modifications to e2e-chatbot-app-next - Keep only the essential bug fix: package name correction - Remove agent code, test files, and investigation docs - Restore original vite.config.ts, databricks.yml, and route files - e2e-chatbot-app-next remains fully independent Changes to e2e-chatbot-app-next vs main: - package.json: Fix invalid package name (databricks/e2e-chatbot-app → @databricks/e2e-chatbot-app) - package-lock.json: Auto-generated from package.json change Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…icks Apps - Remove 'workspaces' field that causes UI build during deployment - Change default 'build' script to only build agent (tsc) - Add 'build:with-ui' for local development with UI - Agent-only deployment doesn't need UI dependencies Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Update build script to build both agent and UI - Modify start.sh to run both servers with concurrently: * Agent on port 5001 (provides /invocations) * UI on port 8000 (serves frontend, proxies to agent) - Add UI route mounting fallback in server.ts - UI accessible at app URL, agent API at /invocations Architecture: - Local dev: Agent (5001) + UI backend (3001) + UI frontend (5000) - Databricks Apps: Agent (5001 internal) + UI (8000 exposed) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Replace npx concurrently with simple background processes - Agent runs on port 5001, UI on port 8000 - Add proper cleanup on exit with trap - Fixes deployment error where npx was not found Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Agent server on port 8000 serves both /invocations and UI static files - Removed complex two-server setup - UI frontend will be served but backend APIs need future work For full UI functionality, the UI backend routes (/api/chat, /api/session, etc) would need to be integrated or proxied to work with the agent. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add /api/session endpoint to provide user authentication - Add /api/config endpoint for app configuration - Add /api/chat endpoint that proxies to /invocations - Add placeholder /api/history and /api/messages endpoints This fixes the 'Authentication Required' error in the UI by providing the backend API routes that the frontend expects. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Convert Responses API SSE format to AI SDK newline-delimited JSON - Add proper Content-Type header for AI SDK (text/plain) - Add X-Vercel-AI-Data-Stream header - Parse SSE events and convert text deltas to AI SDK format - Add logging for debugging This should fix the empty stream issue in the UI. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Log request body being sent to /invocations - Log full error response text when invocations fails - This will help debug the 400 error in production Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The UI sends messages in format:
{
message: { role, parts: [{type, text}] },
previousMessages: [...]
}
But the endpoint was looking for messages: [...] array.
Changes:
- Parse message.parts array to extract text content
- Combine previousMessages + new message into single array
- Convert parts-based format to simple {role, content} format
- Add debug logging for message conversion
Fixes 400 "No user message found in input" error when using the UI.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Architecture: - Agent server (port 5001): Provides /invocations (Responses API) - UI server (port 3001): Provides /api/chat, /api/session, etc. - UI connects to agent via API_PROXY=http://localhost:5001/invocations Changes: - Remove custom /api/chat implementation from agent server - Agent server now only provides /invocations endpoint - UI server (e2e-chatbot-app-next) handles all UI backend routes - Update REQUIREMENTS.md with correct architecture - Document in persistent memory (MEMORY.md) To run locally: npm run dev # Runs both servers with concurrently Key insight: DO NOT modify e2e-chatbot-app-next. It's a standalone UI template that already has proper AI SDK implementation. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
## Production Deployment (Port 8000) Updated start.sh to run both servers in production: - Agent server on port 8001 (internal, provides /invocations) - UI server on port 8000 (exposed, with API_PROXY to agent) This enables the full UI backend + agent architecture in Databricks Apps. ## Tests Added ### 1. endpoints.test.ts - Comprehensive API tests ✅ Tests /invocations Responses API format ✅ Tests Databricks AI SDK provider compatibility ✅ Tests tool calling through /invocations ✅ Tests AI SDK streaming format ### 2. use-chat.test.ts - E2E useChat tests ✅ Tests useChat request format (message + parts) ✅ Tests multi-turn conversations (previousMessages) ✅ Tests tool calling through UI backend ## Test Results All tests passing: - /invocations returns proper Responses API format (SSE) - Format compatible with Databricks AI SDK provider - Tool calling works end-to-end - UI backend properly converts formats Run tests: npm test Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
## Problem
The /invocations endpoint only accepted string content, but the UI backend
(via Databricks AI SDK provider) sends content in array format:
```json
{"role": "user", "content": [{"type": "input_text", "text": "..."}]}
```
This caused useChat integration to fail with 400 errors when the UI backend
tried to call /invocations via API_PROXY.
## Solution
Updated src/routes/invocations.ts to accept BOTH content formats:
1. Simple string: `"content": "text"`
2. Array format: `"content": [{"type": "input_text", "text": "..."}]`
Changes:
- Updated Zod schema to use `z.union([z.string(), z.array(...)])`
- Added content extraction logic to parse array format and extract text
- Maintains backward compatibility with string format
## Validation
Created test-integrations.ts to validate both integrations end-to-end:
✅ Integration 1: /invocations + Databricks AI SDK Provider
- Verifies Responses API format (SSE with text-delta events)
- Tests array content format handling
- Tests tool calling through /invocations
✅ Integration 2: /api/chat + useChat Format
- Verifies UI backend → /invocations via API_PROXY
- Tests full request/response flow
- Verifies SSE streaming with createUIMessageStream format
All automated tests in tests/endpoints.test.ts passing (4/4).
Manual validation with test-integrations.ts: PASS.
Local testing with UI at http://localhost:3002: WORKING.
## Next Steps
- Deploy to Databricks Apps
- Run validation tests against deployed app
- Verify production endpoints work with both formats
- Consider adding /invocations proxy in UI server for external clients
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
TypeScript couldn't infer that content is a string in the else branch. Added 'as string' type assertion to fix build. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Per feedback: 'We shouldn't need too many useChat tests, since those require a fully deployed app including the UI. We should mostly have tests against /invocations, maybe with just one test that does a full useChat against /api/chat under tests/e2e' Changes: - Removed use-chat.test.ts (136 lines) - complex multi-server setup - Keep ONE /api/chat test in deployed.test.ts for E2E coverage - All other tests focus on /invocations endpoint Result: Tests reduced from 1,948 → 1,644 lines (-304 lines, -16%) Test strategy now: - Unit tests: agent.test.ts - Integration: focus on /invocations (integration.test, endpoints.test, error-handling.test) - E2E: deployed.test.ts with one /api/chat test Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Update minimum Node version from 18.0.0 to 22.0.0 for SDK compatibility - Pin @databricks/sdk-experimental to exact version 0.15.0 (remove caret) - Prepares for SDK-based authentication migration
Replace custom authentication logic with @databricks/sdk-experimental: **Changes:** - Use WorkspaceClient for unified authentication chain - Replace manual OAuth2/CLI token fetching with SDK config.authenticate() - Migrate API requests to use apiClient.request() - Remove 92 lines of custom auth code (-18.5%) **Benefits:** - Automatic support for all auth methods (PAT, OAuth, CLI, Azure, GCP) - Token refresh handled by SDK - Better error handling and retries - Consistent with Python template **Technical Details:** - Removed: getOAuth2Token(), getOAuthTokenFromCLI() (58 lines) - Updated: buildHeadersWithToken() to use SDK authenticate() - Updated: linkExperimentToLocation() to use apiClient.request() - Updated: setupExperimentTraceLocation() to use apiClient.request() - Changed: initialize() to create WorkspaceClient instance **Testing:** - ✅ All 6 unit tests pass - ✅ Agent source compiles successfully - ✅ Same functionality, cleaner implementation Lines: 496 → 404 (-92 lines, -18.5%)
- Check for both 'Authorization' and 'authorization' headers - SDK returns lowercase 'authorization', debug log checked uppercase - Now correctly shows 'Auth: Present (Bearer token)'
- Add tests/e2e/**/* to tsconfig exclude - Fixes deployment build failures from pre-existing test import errors - E2E tests still runnable via jest with separate config
- Conditionally serve UI static files when UI_BACKEND_URL is set - Proxy /api/* routes to UI backend server - SPA fallback for client-side routing - Agent-only mode when no UI backend configured Fixes missing UI in deployed Databricks Apps
This commit introduces a plugin-based architecture that allows the agent and UI to run as separate, composable plugins in a single process. Key changes: - Created plugin system foundation (Plugin interface, PluginManager) - Extracted AgentPlugin from existing agent server code - Created UIPlugin that wraps e2e-chatbot-app-next routes - Added unified server entry point (src/main.ts) - Simplified start.sh to use single process - Added npm scripts for different deployment modes The new architecture supports three modes: 1. In-process (both plugins) - Production recommended 2. Agent-only - Just /invocations endpoint 3. UI-only - Proxies to external agent Benefits: - Single process deployment - Simpler orchestration - Follows AppKit-inspired patterns - Maintains backward compatibility - Both plugins can still run standalone Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
TypeScript ES modules require .js extensions in imports even though the source files are .ts. This is required for Node.js ES module resolution. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The UI server should not auto-start when imported as a module by the unified plugin architecture. This allows the UIPlugin to mount the Express app without port conflicts.
Changes: - UIPlugin now mounts UI Express app as sub-application - Updated paths.ts documentation - Documented plugin registration order in main.ts - Updated start.sh to enable in-process mode - UI server no longer auto-starts when imported This completes the implementation of the unified plugin architecture where both agent and UI run in a single process.
Updated regex to exclude /health and /invocations from catch-all route. This allows agent endpoints to work when UI is mounted as sub-application.
This ensures deployments fetch the UI with unified architecture fixes instead of cloning from the main branch. Can be overridden with UI_BRANCH environment variable.
Uses smurching/app-templates for feature/plugin-system branch. Both repo and branch are configurable via environment variables.
The UI server only serves static files in production mode. This enables the React app to load at the root path.
This reverts commit 21e9198.
- Install devDependencies during build (vite, etc.) with --include=dev - Set NODE_ENV=production to enable static file serving - This allows the React app to load in deployed environment
Configure the UI backend to call the agent's /invocations endpoint instead of trying to call DATABRICKS_SERVING_ENDPOINT directly. This fixes the deployed app where the UI backend was unable to communicate with the agent, resulting in "Please set the DATABRICKS_SERVING_ENDPOINT environment variable" errors. In the unified plugin architecture, the UI backend should proxy all AI requests to the local agent's /invocations endpoint via the API_PROXY environment variable. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Remove 214 lines of redundant code by eliminating server.ts, which duplicated functionality already implemented in the plugin system. All server logic now lives directly in AgentPlugin, making the architecture cleaner and easier to understand. Changes: - Delete src/server.ts (redundant wrapper eliminated) - Update package.json scripts to use unified server (main.ts) - Add maxRetries: 3 to ChatDatabricks for rate limit handling - Fix test authentication headers for /api/chat endpoint - Update endpoints.test.ts to use unified server instead of spawning server.ts - Update documentation to reflect plugin-based architecture - Update skill guides to reference correct file paths Test Results: - Unit tests: 6/6 passing - Integration tests: Individual suites all pass - Production deployment: Verified working Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
smurching
changed the title
Critical fixes: - setup-ui.sh: add TODO to switch to official repo before merge - Remove duplicate SIGINT/SIGTERM handlers (drop setupTracingShutdownHandlers call, have AgentPlugin.shutdown() flush/shutdown tracing directly) - Restore e2e-chatbot-app-next standalone mode with isMainModule guard High priority: - Remove unused PluginContext interface and simplify PluginManager constructor - Update AGENTS.md and CLAUDE.md to reflect plugin architecture (remove server.ts refs) - Delete working notes files (E2E_TEST_RESULTS, TEST_RESULTS, UI_STATIC_FILES_ISSUE) - Add comment to Mode 3 skip explaining E2E coverage rationale Medium priority: - Fix AgentExecutor | any type to use StandardAgent - Store ucTableName on MLflowTracing instance instead of mutating process.env - Document globalMCPClient singleton contract for test isolation - Move predev UI setup hook to explicit npm run setup command - UIPlugin now falls back to getDefaultUIRoutesPath() instead of relative string - isMainModule() check now matches dist/src/main.js (not any main.js) - Add cross-reference comments to both proxy implementations Minor: - weatherTool description now indicates it returns mock/random data - Signal handlers moved to end of initialize() not injectAllRoutes() - Replace Date.now() tool call IDs with crypto.randomUUID() - Fix inconsistent model name example in README (gpt-5-2 → dbrx-instruct) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
smurching
commented
Feb 23, 2026
| @@ -0,0 +1,12 @@ | |||
| #!/bin/bash | |||
| # UI build wrapper that skips if dist folders already exist | |||
Collaborator
Author
There was a problem hiding this comment.
Is this actually necessary? Why so many different scripts?
isMainModule was calling fileURLToPath(process.argv[1]) but process.argv[1] is already a file path (not a file:// URL), causing TypeError: Invalid URL whenever UIPlugin tried to import the UI server module. Fix: compare process.argv[1] directly to fileURLToPath(import.meta.url). Also add full error stack logging in UIPlugin to make future import failures easier to debug. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add CUSTOMIZE/FRAMEWORK markers to source files so humans and AI can immediately identify which files to modify vs. leave alone - Update run-locally skill to reflect actual dev workflow: dev:agent for hot-reload, dev:legacy for full stack, npm start for production build - Fix stale src/server.ts reference in run-locally troubleshooting section - Add npm run setup step to quickstart skill Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Users only need to edit the 3 files at the root of src/: - src/agent.ts (system prompt, model config) - src/tools.ts (tool definitions) - src/mcp-servers.ts (MCP server connections) Everything else (plugin system, tracing, invocations endpoint) moves to src/framework/, which signals by its name that it's infrastructure not meant to be modified by users or agent authors. Also revert file-level FRAMEWORK/CUSTOMIZE banner comments (redundant now that the directory structure makes the intent clear) and update skills, AGENTS.md, and CLAUDE.md to reflect the new layout. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Framework tests (infrastructure, no need to modify): - tests/endpoints.test.ts → tests/framework/endpoints.test.ts - tests/plugin-system.test.ts → tests/framework/plugin-system.test.ts - tests/plugin-integration.test.ts → tests/framework/plugin-integration.test.ts - tests/e2e/tracing.test.ts → tests/e2e/framework/tracing.test.ts User code tests (customize freely): - tests/agent.test.ts, integration.test.ts, error-handling.test.ts remain at top level - tests/e2e/deployed.test.ts, followup-questions.test.ts, ui-auth.test.ts remain in e2e/ Also fix pre-existing bug: e2e tests were importing from ./helpers.js (non-existent path) — corrected to ../helpers.js. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Keeps only user-facing tests (agent.test.ts, deployed.test.ts) at the top level of tests/ and tests/e2e/, making it clear which tests users need to think about vs. which are infrastructure they can ignore. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
dist/ and ui/ are gitignored so they aren't uploaded by DABs. Instead of erroring out on first deploy, build them on startup. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Remove weather and calculator tools to reduce the amount of code new agent authors need to reason about. Also removes the mathjs dependency. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
All tests were marked CURRENTLY FAILS; streaming now works via StandardAgent.stream() and is covered by endpoints.test.ts. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Introduces a plugin-based unified server architecture for
agent-langchain-tsthat allows the LangChain agent backend and thee2e-chatbot-app-nextUI to run in a single process on Databricks Apps — while keeping each component independently testable and deployable.Architecture
The new architecture replaces a standalone
server.tswith aPluginManagerthat composes two self-contained plugins:Three deployment modes:
npm run dev(port 8000)npm run dev:agent(port 5001)AGENT_INVOCATIONS_URLRoute precedence: AgentPlugin registers
/healthand/invocationsfirst; UIPlugin mounts/api/*and static files after — ensuring agent endpoints are never shadowed.Key Changes
src/main.ts— Unified server replacing the oldserver.tssrc/plugins/— Plugin system (PluginManager, AgentPlugin, UIPlugin)app.yaml— SetsAPI_PROXYso UIPlugin can reach the agent in productione2e-chatbot-app-next/server/src/index.ts— Restored standalone mode withisMainModuleguard so the UI still works independentlyscripts/setup-ui.sh— Setup script to fetch the UI template (uses fork temporarily; see TODO in file)tests/plugin-integration.test.ts— Integration tests for all three deployment modesTesting
All tests pass locally:
Tested on deployed Databricks App:
/healthreturns 200/invocationsstreams SSE correctly/api/chatresponds in AI SDK formatNotes
setup-ui.shcurrently points to a personal fork (smurching/app-templates) onfeature/plugin-systembecausee2e-chatbot-app-nextchanges haven't merged to main yet. There is a TODO in the script to switch to the official repo before this PR merges.src/tracing.tsstill exportssetupTracingShutdownHandlers(no longer called by the plugin system, but kept to avoid breaking any external consumers).🤖 Generated with Claude Code