reference ~14 min
TPipe-Defaults Package API

- [Overview](#overview)

Table of Contents

Overview

The TPipe-Defaults package provides pre-configured factories and builders for creating Manifold instances, pipelines, and reasoning systems with provider-specific optimizations for AWS Bedrock, Ollama, and other LLM providers.


Configuration Classes

ProviderConfiguration

Abstract base class for provider-specific configuration parameters.

sealed class ProviderConfiguration

Public Functions

validate(): Boolean Validates configuration parameters for the provider.

Behavior: Abstract method implemented by each provider to ensure required parameters are present and valid.


BedrockConfiguration

Configuration for AWS Bedrock provider with comprehensive AWS integration.

data class BedrockConfiguration(
    var region: String,
    var model: String,
    var pipeCount: Int = 2,
    var inferenceProfile: String = "",
    var useConverseApi: Boolean = true,
    var accessKey: String? = null,
    var secretKey: String? = null,
    var sessionToken: String? = null,
    var profileName: String? = null
) : ProviderConfiguration()

Public Properties

Core Settings:

  • region: AWS region for Bedrock API calls (required)
  • model: Bedrock model identifier (required)
  • pipeCount: Number of pipes to create in manager pipeline (default: 2)

Advanced Settings:

  • inferenceProfile: Optional inference profile for binding calls
  • useConverseApi: Whether to use Converse API vs Invoke API (default: true)

Authentication:

  • accessKey / secretKey - AWS credentials (optional if using profile/IAM)
  • sessionToken: AWS session token for temporary credentials
  • profileName: AWS profile name to use

Public Functions

validate(): Boolean Validates Bedrock configuration parameters.

Behavior: Ensures region and model are non-blank and pipeCount is positive.

make(region: String, model: String) Configures Bedrock settings with automatic inference profile detection.

Behavior: Sets region and model, automatically retrieves inference profile ID if available.


OllamaConfiguration

Configuration for Ollama provider with local server settings.

data class OllamaConfiguration(
    val model: String,
    val pipeCount: Int = 2,
    val host: String = "localhost",
    val port: Int = 11434,
    val timeout: Long = 30000,
    val useHttps: Boolean = false
) : ProviderConfiguration()

Public Properties

Core Settings:

  • model: Model name to use (required)
  • pipeCount: Number of pipes in manager pipeline (default: 2)

Connection Settings:

  • host: Ollama server host (default: “localhost”)
  • port: Ollama server port (default: 11434)
  • timeout: Connection timeout in milliseconds (default: 30000)
  • useHttps: Whether to use HTTPS (default: false)

Public Functions

validate(): Boolean Validates Ollama configuration parameters.

Behavior: Ensures host and model are non-blank, port and pipeCount are positive.


Factory Classes

ManifoldDefaults

Central factory for creating pre-configured Manifold instances with provider-specific defaults.

For the actual startup sequence after creating a manifold, see Manifold - Multi-Agent Orchestration. ManifoldDefaults creates the manager side, but you still need worker pipelines and init() before execution.

If you want TPipe-Defaults to configure the manager and manager-memory policy inside the new Kotlin manifold DSL, use manifold { defaults { bedrock(...) } } or manifold { defaults { ollama(...) } }.

object ManifoldDefaults

Public Functions

withBedrock(configuration: BedrockConfiguration): Manifold Creates Manifold instance configured for AWS Bedrock.

Behavior:

  • Validates configuration parameters
  • Creates Bedrock-optimized Manifold with manager pipeline
  • Throws IllegalArgumentException for invalid configuration
  • Throws RuntimeException if Bedrock provider unavailable

withOllama(configuration: OllamaConfiguration): Manifold Creates Manifold instance configured for Ollama.

Behavior:

  • Validates configuration parameters
  • Creates Ollama-optimized Manifold with manager pipeline
  • Throws IllegalArgumentException for invalid configuration
  • Throws RuntimeException if Ollama provider unavailable

getAvailableProviders(): List<String> Lists all available providers with implementations.

Behavior: Checks class availability and returns list of provider names (“bedrock”, “ollama”).

isProviderAvailable(providerName: String): Boolean Checks if specific provider is available.

Behavior: Uses reflection to check for provider class availability, returns false for ClassNotFoundException.

buildDefaultManagerPipeline(bedrockConfig: BedrockConfiguration): Pipeline Creates pre-configured manager pipeline for Bedrock.

Behavior:

  • Creates 2-pipe manager pipeline with task analysis and agent selection
  • Applies comprehensive default prompts and settings
  • Configures JSON input/output for TaskProgress and AgentRequest

buildDefaultManagerPipeline(ollamaConfig: OllamaConfiguration): Pipeline Creates pre-configured manager pipeline for Ollama.

assignManagerPipelineDefaults(pipeline: Pipeline): Pipeline Applies default configuration to manager pipelines.

Behavior:

  • Entry Pipe: Analyzes task completion status, outputs TaskProgress
  • Agent Selector Pipe: Determines next agent to call, outputs AgentRequest
  • Configuration: Sets temperature, context windows, truncation, prompts
  • Validation: Requires exactly 2 pipes in pipeline

BedrockDefaults

Internal factory for Bedrock-specific Manifold creation.

internal object BedrockDefaults

Public Functions

createManifold(config: BedrockConfiguration): Manifold Creates basic Bedrock-configured Manifold.

createManagerPipeline(config: BedrockConfiguration): Pipeline Creates manager pipeline with specified number of Bedrock pipes.

createWorkerPipe(config: BedrockConfiguration): BedrockMultimodalPipe Creates worker pipe with Bedrock configuration.

createBedrockPipe(config: BedrockConfiguration): BedrockMultimodalPipe Creates fully configured BedrockPipe.

Behavior:

  • Sets model (uses inference profile if provided)
  • Configures AWS region
  • Enables Converse API if specified

OllamaDefaults

Internal factory for Ollama-specific Manifold creation.

internal object OllamaDefaults

Public Functions

createManifold(config: OllamaConfiguration): Manifold Creates basic Ollama-configured Manifold.

createManagerPipeline(config: OllamaConfiguration): Pipeline Creates manager pipeline with specified number of Ollama pipes.

createWorkerPipe(config: OllamaConfiguration): OllamaPipe Creates worker pipe with Ollama configuration.

createOllamaPipe(config: OllamaConfiguration): OllamaPipe Creates fully configured OllamaPipe.

Behavior:

  • Sets model name
  • Configures host IP and port
  • Sets TaskProgress as JSON input

PumpStationDefaults

Central factory for creating pre-configured PumpStation instances with provider-specific defaults. Mirrors the shape of ManifoldDefaults but targets the PumpStation runtime-harness class. Each with* entry point returns a fully-wired station ready to receive executeLocal calls; the caller may further customize the result by passing a configure: PumpStationBuilder.() -> Unit block.

The recommended recommendedMemoryConfig() default is (Truncation, 0.85) so a first live run is cheap to debug. Developers who want the v3 compaction path can assign memoryManagementMode = PumpStationMemoryManagementMode.Compaction in the builder block.

Cross-reference: the prompt strings used as the judge/dispatch defaults live in Pipeline/PumpStationDefaults.kt (made public for this purpose).

object PumpStationDefaults

Public Properties

None — PumpStationDefaults exposes only functions.

Public Functions

recommendedMemoryConfig(): Pair<PumpStationMemoryManagementMode, Double>

Returns the recommended memory configuration for a first live run. Defaults to (Truncation, 0.85). Truncation is the pre-v3 path that has shipped in the codebase the longest and is cheaper to debug on a first run. Developers who want the v3 compaction default can assign memoryManagementMode = Compaction in the builder block, or override this entire pair via the DSL.

recommendedKillSwitchConfig(): KillSwitchConfig

Returns the recommended kill-switch configuration: a 50K input-token cap and a 10K output-token cap. Generous enough for a 10-turn multi-path task on a small model, tight enough to halt a runaway loop before the operator has to kill -9 the JVM.

withOpenRouter(configuration: OpenRouterConfiguration, configure: PumpStationBuilder.() -> Unit = {}): PumpStation

Creates a PumpStation configured for OpenRouter with optimized defaults. The returned station has:

  • judgeAgent = a single OpenRouterPipe pipeline with DEFAULT_JUDGE_PROMPT
  • dispatchAgent = a single OpenRouterPipe pipeline with DEFAULT_DISPATCH_PROMPT
  • killSwitch = the result of recommendedKillSwitchConfig()
  • memoryManagementMode = the first element of recommendedMemoryConfig()
  • compactionThreshold = the second element of recommendedMemoryConfig()
  • tracingEnabled = true (the developer can disable via the builder block by setting tracingConfiguration = null or to a disabled config)

Note: the factory itself does not register any paths — PumpStationBuilder.build() requires at least one path. The caller must register at least one path either in the configure block or by calling addPath / addReservePath on the returned station before executeLocal.

import Defaults.OpenRouterConfiguration
import Defaults.PumpStationDefaults
import com.TTT.Pipe.MultimodalContent
import com.TTT.Pipeline.PumpStation
import com.TTT.Pipeline.PumpStationJudgeRunMode

fun buildResearchStation(apiKey: String): PumpStation
{
    val config = OpenRouterConfiguration(
        model = "openai/gpt-4o-mini",
        apiKey = apiKey,
        pipeCount = 1
    )

    return PumpStationDefaults.withOpenRouter(config) {
        // Override the recommended kill switch for a tighter run
        killSwitchConfiguration = com.TTT.P2P.KillSwitch(
            inputTokenLimit = 100_000,
            outputTokenLimit = 20_000
        )

        // Path with execution function
        path("answer") {
            description = "Produces a one-sentence answer and signals pass-pipeline."
            setExecutionFunction { content, _, _, _ ->
                MultimodalContent(text = "ok: ${content.text}").apply {
                    passPipeline = true
                }
            }
        }
    }
}

The configure block runs after the defaults are wired, so any setting the developer assigns overrides the factory’s defaults. The block has the same surface as the top-level pumpStation { } builder — see PumpStation API Reference for the full builder block reference.

Throws IllegalArgumentException if the OpenRouter configuration is invalid, or RuntimeException (wrapping the original cause) if the station cannot be built.

KillSwitchConfig

Data carrier for PumpStationDefaults.recommendedKillSwitchConfig. Plain data class so the values can be unpacked into the KillSwitch constructor at the call site.

data class KillSwitchConfig(
    val inputTokenLimit: Int? = 50_000,
    val outputTokenLimit: Int? = 10_000
)
PropertyTypeDefaultDescription
inputTokenLimitInt?50_000Maximum input tokens (prompt + context). null disables the input limit.
outputTokenLimitInt?10_000Maximum output tokens (response + reasoning). null disables the output limit.

Default Prompts

PumpStationDefaults does not own the prompt strings — they live in Pipeline/PumpStationDefaults.kt and are public so the factory can reference them. The full text of every default prompt is documented in PumpStation Magic Contracts:

  • DEFAULT_JUDGE_PROMPT — judge agent system prompt
  • DEFAULT_DISPATCH_PROMPT — dispatch agent system prompt
  • DEFAULT_GOAL_PROMPT — goal agent system prompt (internal)
  • DEFAULT_PATH_SAFETY_PROMPT — path-safety agent system prompt
  • DEFAULT_HEALTH_PROMPT — health agent system prompt
  • DEFAULT_LOREBOOK_PROMPT — lorebook agent system prompt
  • DEFAULT_JUDGE_FOOTER — judge agent footer prompt (internal)
  • DEFAULT_DISPATCH_FOOTER — dispatch agent footer prompt (internal)

The placeholders in the prompts ({personality}, {systemTask}, {userGuidelines}, {entryUserPrompt}) are filled in by the harness’s prompt builders at runtime — see buildJudgeSystemPrompt, buildDispatchSystemPrompt, and buildGoalSystemPrompt in Pipeline/PumpStationHelpers.kt.

Live Example

TPipe-Defaults/src/main/kotlin/examples/pumpstation/PumpStationOpenRouterExample.kt contains a runnable main() that demonstrates all four exit mechanisms (always-on judge, FlagTriggered judge, path passPipeline, kill switch trip) against a live OpenRouter model.

To run:

export OPENROUTER_API_KEY=sk-or-...
./gradlew :TPipe-Defaults:run --args="pumpStationOpenRouter"

The example prints OK on success and the exitReason from taskState.


Reasoning System

ReasoningBuilder

Factory for creating reasoning-enabled pipes with various thinking strategies.

object ReasoningBuilder

Public Functions

assignDefaults(settings: ReasoningSettings, pipeSettings: PipeSettings, targetPipe: Pipe) Applies reasoning configuration to existing pipe.

Behavior:

  • System Prompt Assignment: Sets reasoning-specific prompts based on method
  • JSON Configuration: Configures appropriate input/output objects for reasoning type
  • Settings Application: Applies temperature, tokens, context window settings
  • Multi-Round Support: Uses roundDirectives as the canonical blind/merge configuration. Blind rounds are isolated by the harness, merge rounds synthesize the accumulated flattened thought stream, and legacy focusPoints remains available only when no round directives are supplied
  • Metadata Binding: Stores reasoning configuration in pipe metadata

reasonWithBedrock(bedrockConfig: BedrockConfiguration, reasoningSettings: ReasoningSettings, pipeSettings: PipeSettings): Pipe Creates Bedrock reasoning pipe with defaults.

Behavior: Creates BedrockPipe, applies reasoning defaults, returns as generic Pipe.

reasonWithOllama(ollamaConfig: OllamaConfiguration, reasoningSettings: ReasoningSettings, pipeSettings: PipeSettings): Pipe Creates Ollama reasoning pipe with defaults.

Behavior: Creates OllamaPipe, applies reasoning defaults, returns as generic Pipe.

ReasoningPrompts

Static prompts for different reasoning strategies.

object ReasoningPrompts

Public Functions

chainOfThoughtSystemPrompt(depth: String = "", duration: String = "", method: ReasoningMethod = ReasoningMethod.StructuredCot): String Generates system prompts for chain-of-thought reasoning.

Behavior:

  • Explicit Reasoning: Step-by-step analysis with clear transitions
  • Structured CoT: Phase-based framework (analyze→plan→execute→validate)
  • Process-Focused: Methodological justification and adaptive thinking

bestIdeaPrompt(): String Prompt for single best idea generation.

comprehensivePlanPrompt(): String Prompt for comprehensive planning approach.

rolePlayPrompt(character: String): String Prompt for character-based reasoning.

semanticDecompressionPrompt(depth: ReasoningDepth = ReasoningDepth.Med, duration: ReasoningDuration = ReasoningDuration.Med): String Prompt for legend-backed semantic decompression reasoning with structured quote, sentence, and paragraph reconstruction.

selectDepth(depth: ReasoningDepth): String Returns depth-specific reasoning instructions.

selectDuration(duration: ReasoningDuration): String Returns duration-specific reasoning instructions.


Enums

ReasoningMethod

enum class ReasoningMethod {
    BestIdea,           // Single best solution approach
    ComprehensivePlan,  // Detailed planning strategy
    ExplicitCot,        // Step-by-step reasoning
    StructuredCot,      // Phase-based framework
    processFocusedCot,  // Methodological focus
    RolePlay,           // Character-based reasoning
    SemanticDecompression // Legend-backed prompt reconstruction with structured restoration fields
}

ReasoningInjector

enum class ReasoningInjector {
    SystemPrompt,                    // End of system prompt
    BeforeUserPrompt,               // Before user input
    BeforeUserPromptWithConverse,   // In ConverseHistory before user
    AfterUserPrompt,                // After user input
    AfterUserPromptWithConverse,    // In ConverseHistory after user
    AsContext                       // As context page key
}

ReasoningDepth

enum class ReasoningDepth { Low, Med, High }

ReasoningDuration

enum class ReasoningDuration { Short, Med, Long }

ReasoningSettings

Configuration for reasoning behavior.

data class ReasoningSettings(
    var reasoningMethod: ReasoningMethod = ReasoningMethod.StructuredCot,
    var depth: ReasoningDepth = ReasoningDepth.Med,
    var duration: ReasoningDuration = ReasoningDuration.Med,
    var roleCharacter: String = "You are an automated security auditor responsible for identifying PII leakage in application logs.",
    var reasoningInjector: ReasoningInjector = ReasoningInjector.SystemPrompt,
    var numberOfRounds: Int = 1,
    var focusPoints: MutableMap<Int, String> = mutableMapOf(),
    var roundDirectives: MutableMap<Int, ReasoningRoundDirective> = mutableMapOf()
)

ReasoningRoundDirective

Round-scoped configuration for multi-round reasoning.

data class ReasoningRoundDirective(
    var focusPoint: String = "",
    var mode: ReasoningRoundMode = ReasoningRoundMode.Blind
)

ReasoningRoundMode

enum class ReasoningRoundMode {
    Blind,
    Merge
}

Manifold DSL Integration

TPipe-Defaults provides extension functions that bridge the defaults module into the Manifold DSL. This lets you use defaults { bedrock(...) } or defaults { ollama(...) } inside a manifold { } block to configure the manager pipeline and history policy from provider defaults.

ManifoldDsl.defaults(block)

Entry point for defaults-backed configuration inside the manifold DSL.

import com.TTT.Pipeline.manifold
import Defaults.BedrockConfiguration
import Defaults.defaults

val builtManifold = manifold {
    defaults {
        bedrock(BedrockConfiguration(
            region = "us-east-1",
            model = "anthropic.claude-3-haiku-20240307-v1:0"
        ))
    }

    worker("my-worker") {
        description("Does work.")
        pipeline(workerPipeline)
    }
}

Behavior: The defaults block creates a DefaultsManifoldDsl receiver that exposes bedrock(...) and ollama(...) methods. Each method:

  1. Validates the provider configuration
  2. Builds the default manager pipeline via ManifoldDefaults.buildDefaultManagerPipeline(...)
  3. Configures the manager { } block with the built pipeline and the standard "Agent caller pipe" dispatch name
  4. Configures the history { } block with the provider’s ManifoldMemoryConfiguration (truncation method, context window size, token budget)

HistoryDsl.applyDefaults(memoryConfiguration)

Applies a ManifoldMemoryConfiguration to the DSL history block. This mirrors the memory settings that ManifoldDefaults.withBedrock(...) or ManifoldDefaults.withOllama(...) would apply when using the non-DSL path.

The applied settings include:

  • managerTruncationMethoddefaultsTruncationMethod(...)
  • managerContextWindowSizedefaultsContextWindowSize(...)
  • enableManagerBudgetControlautoTruncate()
  • managerTokenBudgetmanagerTokenBudget(...)

DistributionGrid DSL Integration

TPipe-Defaults also provides extension functions that bridge provider defaults into the DistributionGrid DSL. This lets you use defaults { bedrock(...) } or defaults { ollama(...) } inside a distributionGrid { } block to configure a provider-backed router and worker without embedding provider logic into core DistributionGrid.

DistributionGridDsl.defaults(block)

Entry point for defaults-backed configuration inside the grid DSL.

import Defaults.BedrockGridConfiguration
import Defaults.defaults
import com.TTT.Pipeline.distributionGrid

val grid = distributionGrid {
    defaults {
        bedrock(
            BedrockGridConfiguration(
                region = "us-east-1",
                model = "anthropic.claude-3-haiku-20240307-v1:0"
            )
        )
    }
}

Behavior: The defaults block creates a DefaultsDistributionGridDsl receiver that exposes bedrock(...) and ollama(...) methods. Each method:

  1. Validates the provider configuration
  2. Builds a provider-backed default router pipeline via DistributionGridDefaults.buildDefaultRouterPipeline(...)
  3. Builds a provider-backed default worker pipeline via DistributionGridDefaults.buildDefaultWorkerPipeline(...)
  4. Seeds the root DistributionGridDsl with those required roles
  5. Applies any explicitly supplied optional node-level defaults such as P2P identity, routing policy, memory policy, tracing, discovery, durability, or operational limits

Conflict behavior:

  • defaults always own the router and worker roles
  • if the caller already configured a conflicting singleton concern, the DSL fails fast instead of silently overriding it
  • non-conflicting additive concerns like peer(...) and peerDescriptor(...) remain available

DistributionGridDefaults

TPipe-Defaults also exposes raw defaults factories for non-DSL callers:

  • DistributionGridDefaults.withBedrock(...)
  • DistributionGridDefaults.withOllama(...)

These factories use the same defaults-seeding path as the DSL bridge so the raw and DSL behaviors stay aligned.

Hosted Registry Helpers

TPipe-Defaults also exposes thin hosted-registry ergonomics helpers that return the shipped runtime types directly.

HostedRegistryDefaults

Primary helpers:

  • buildRegistryHost(...)
  • buildPublicRegistryHost(...)
  • buildPrivateRegistryHost(...)
  • trustedPublicAgentSource(...)
  • bootstrapCatalogSource(...)
  • publicListingOptions(...)

These helpers intentionally do not introduce a second runtime layer. They only compose:

  • P2PHostedRegistry
  • P2PTrustedRegistrySource
  • DistributionGridBootstrapCatalogSource
  • DistributionGridPublicListingOptions

The defaults stay explicit:

  • file-backed hosted registries still require an explicit durable file path
  • trusted-source helpers remain AGENT-only
  • grid bootstrap helpers remain GRID_REGISTRY-only
  • no helper auto-publishes, auto-imports, or starts renew/refresh loops by surprise

Key Behaviors

Provider Abstraction

Unified interface for different LLM providers while maintaining provider-specific optimizations and configurations.

Default Configuration

Comprehensive default settings for common use cases, reducing setup complexity while maintaining flexibility for customization.

Reasoning Integration

Sophisticated reasoning system that transforms standard pipes into thinking systems for LLMs without native reasoning support.

Error Handling

Robust validation and error reporting with descriptive messages for configuration issues and provider availability.

Extensibility

Modular design allows easy addition of new providers and reasoning methods without affecting existing functionality.