Skip to main content

Nambikk Architect

Nambikk Architect is a conversational Studio co-designer. It can discuss an agent or capability, prepare a complete set of changes, validate the proposed capability DSL, and apply only the changes that a builder approves.

Architect does not own a second capability editor. Existing capabilities always remain in the canonical Capability Editor, and the capability DSL remains the source of truth.

Experience Model​

Architect has two deliberately different entry points.

Existing Agents And Capabilities​

Architect opens as a resizable dock beside the page the builder is already using.

  • On an agent page, it can discuss and propose agent settings, capabilities, datapoints, integrations, actions, and knowledge changes.
  • On a capability page, the canonical journey canvas stays visible. A proposed DSL is rendered by the same BranchCanvas component and changed activities are highlighted in place.
  • The dock has one natural-language conversation input. There are no separate Discuss and Propose commands.
  • A conversational question produces an answer without changing the current proposal.
  • A clear edit request creates a new reviewable proposal.

The dock switches between Conversation and Review changes only while a proposal is awaiting a decision. Review shows the compiler result, journey changes, supporting resource changes, and the real Discard and Approve actions.

New Agents​

/studio/architect/new is a temporary drafting workspace used only before an agent and capability exist.

  1. The builder describes the agent, first capability, journey, systems, data, and knowledge in ordinary language.
  2. Architect presents a readable draft document beside the persistent conversation.
  3. The document shows the proposed agent identity, first capability, ordered journey, compiler result, resource changes, and setup work that still needs credentials or documents.
  4. The builder can keep conversing and revise the same design with context.
  5. Create agent applies the selected changes, creates and compiles the capability, and opens the canonical Capability Editor.

The workspace stores its session ID in the URL. Refreshing or reopening that URL restores the draft, conversation, current proposal, compiler result, and patch review instead of returning to an empty brief.

There is no journey canvas in this temporary workspace because no canonical capability exists yet. Once created, all further journey work happens in the real editor with the Architect dock.

Proposal Lifecycle​

Each session has at most one current reviewable proposal.

flowchart LR
  Request["Builder request"] --> Intent{"Conversation or edit?"}
  Intent -->|Conversation| Reply["Contextual reply"]
  Intent -->|Edit| Draft["Generate full draft"]
  Draft --> Validate["Compile and validate"]
  Validate --> Review["Review current proposal"]
  Review -->|Revise| Draft
  Review -->|Discard| Current["Keep current Studio state"]
  Review -->|Approve| Apply["Apply selected patches"]
  Apply --> Canonical["Canonical agent and capability"]
  • A newer proposal makes the previous proposal stale. It cannot be applied accidentally.
  • A revision treats the current proposal as its baseline. Agent identity, persona, tone, guardrails, resources, and unchanged DSL fields are preserved unless the builder explicitly asks to change or remove them.
  • Proposal application revalidates the selected change set immediately before mutation.
  • Rejecting a proposal restores the saved capability preview.
  • Applying a capability proposal updates the canonical capability, compiles it, and preserves its existing activation state.
  • Greenfield application creates the agent first, then dependent resources and the first capability, and binds the Architect session to those new records.
  • Resource selection is dependency-aware. A dependent capability cannot be selected while a required ready resource is omitted.

Supported Changes​

Architect can prepare executable patches for:

  • Creating an agent and its first capability.
  • Updating agent description, persona, tone, compliance instructions, and capability activation.
  • Creating or replacing a capability DSL journey.
  • Creating datapoints required by collect or confirm activities.
  • Creating REST integrations and actions, including base URL, authentication shape, API-key header name, request method, endpoint, schemas, mappings, and outcomes.
  • Identifying an existing integration that still needs authorization.
  • Creating and attaching knowledge collections.

Integration credentials are never collected in Architect conversation or stored in a proposal. Authentication type and header names are configuration; secret values remain a separate Integration settings task.

Review Contract​

Review is a representation of the actual pending patch set, not a demonstration screen.

  • Compiler status comes from the real capability compiler.
  • Journey changes are computed from the saved and proposed DSL and identify added, removed, and semantically changed activities.
  • Canvas highlights use the same comparison and appear on the canonical journey canvas.
  • Resource changes are the concrete patches that will be sent to Studio services.
  • Needs configuration items remain visible but cannot be falsely approved as complete.
  • Approve applies the currently selected executable patches.
  • Discard rejects the proposal without changing canonical Studio records.

The product does not expose Original, Proposed, Diff, Details, DSL, or Test tabs inside Architect. Source editing belongs to the Capability Editor, and tests should only be exposed when a real production test runner is connected.

Conversation Intent​

Architect routes each message before generating a proposal.

  • Greetings, questions, explanations, reviews, recommendations, and ambiguous exploration stay conversational.
  • Clear create requests produce a build proposal.
  • Clear add, change, remove, reconnect, or simplify requests produce a revision.
  • Explicit compiler repair requests produce a repair proposal.
  • Phrases such as "do not modify the proposal" override edit words in the same message and keep the turn conversational.

This lets a builder ask what changed, why a branch exists, or where to review it without silently replacing the proposal being discussed.

Safety And Production Rules​

  • The capability DSL remains the durable source of truth.
  • No proposed mutation is applied without an explicit builder decision.
  • Secrets, passwords, tokens, client secrets, and API keys are never requested in chat or written into patches.
  • External credentials and knowledge documents are reported as setup work, not falsely marked complete.
  • Unsupported changes are reported honestly instead of rendered as fake controls.
  • Compiler failures block application of a capability change.
  • Agent, capability, and workspace sessions retain their own conversation context and proposal history.
  • Architect patch application uses the same tenant-scoped Studio services as manual configuration.

Verification Expectations​

Meaningful Architect changes should verify:

  • Conversation-only turns do not create or replace a proposal.
  • New edit turns supersede older reviewable proposals.
  • Current-only apply and reject guards work.
  • Capability proposals compile before and immediately before application.
  • Greenfield creation binds the session to the created agent and capability.
  • Dependency selection remains valid for resources and capabilities.
  • Existing capabilities render current and proposed DSL through the same canvas.
  • Discard restores the saved journey and Approve persists the proposed journey.
  • The platform build and focused Architect unit and component tests pass.
  • Browser QA covers the new-agent brief, conversational revision, existing capability proposal review, and authorization setup states.