# Learning Palantir Foundry 🚀 The first move that turns a dataset into a business object. How you design Object Types largely decides downstream app performance and UX. 📌 Title and Feature URL Title: オブジェクトタイプ URL: 📝 Overview An Object Type defines the schema for a real-world entity or event. A single occurrence is an object instance (e.g., employee "Melissa Chang"), while a group is an object set (e.g., all tenured employees). This mirrors how datasets handle rows and filtered row collections. 🔧 How It Works - Primary keys and identity: objects need a primary key to uniquely identify instances. Mapping a data source to the object type lets you create and display objects in applications. - Properties: define an object's characteristics, with options such as edit-only properties, required properties, and shared properties reused across multiple object types. - Property types: support time series data, geospatial information, and struct types (nested, complex properties). - Display and search: title/display settings and search indexing improve discoverability inside apps. - Value Types: custom value types with versions, permissions, and constraints standardize representation across the ontology. 🛠 Practical Usage - Connect an employee directory or enterprise data to an Employee object type, converting raw datasets into actionable ontology instances. - Nail down primary key design first and index for search to secure downstream app performance and UX. - Use struct properties to auto-map hierarchical data, combined with shared properties for reuse. 🎯 Use Cases - Turn a customer master into a Customer object so the whole company shares one identity. - Model sensor-equipped assets with time series properties to retain operating history. - Model sites and stores with geospatial properties for map-based search and aggregation. ⚠️ Caveats - Primary key design, property types, and search indexing largely determine later app performance and UX, so treat them as your most important modeling decisions. - You must correctly map a data source to the object type before objects can be created or displayed. #PalantirFoundry# #Ontology#

# Learning Palantir Foundry 🚀 Action Types are what decisively separate Foundry from read-only BI. Approvals and assignments become safe, validated, structured writes. 📌 Title and Feature URL Title: アクションタイプ URL: 📝 Overview An Action Type defines a set of changes a user can apply to ontology objects, properties, and links in a single transaction. It encapsulates both the data modifications and any side effects triggered on submission, letting users think in terms of overall goals rather than individual property edits. 🔧 How It Works - Write-back to the ontology: when an action runs, all changes are committed to the ontology and reflected across every app. The latest object data, including user edits, is captured in the object type's write-back dataset. - Parameters and defaults: parameters standardize input, supporting default values, filtered dropdown results, and overrides. - Rules: define when and how an action executes, including object relationships and property constraints. - Submission criteria and validation: validation rules control execution eligibility and error handling before changes persist. - Action logs: a full audit trail of every executed action supports accountability and compliance. 🛠 Practical Usage - Run an "Assign Employee" style action that changes a role property, auto-creates a manager-employee link, and notifies stakeholders in one transaction. - Embed submission criteria like "only a director may submit amounts over 1M yen" as validation, replacing Excel-plus-email approvals with structured operations. - Reuse the same validation logic and workflow consistently across every user-facing app. 🎯 Use Cases - Standardize status changes, approvals, and assignments as permissioned, criteria-bound operations. - Let non-technical users safely execute multi-step changes spanning several objects. - Use the action log of every operation as an audit trail for internal controls. ⚠️ Caveats - Actions execute only after passing their validation rules, so submission-criteria design drives the quality of your controls. - Changes propagate immediately across the ontology and all apps, so do not leave rule and parameter design ambiguous. #PalantirFoundry# #Ontology#

# ADK 2.0の便利だけど知られていない機能 🌍 数分〜数時間かかる処理をエージェントのツールとして扱いたい場合、どうすればよいでしょうか？ ADK 2.0の `LongRunningFunctionTool` は、長時間実行されるタスクのオーケストレーションを管理するための専用クラスです。実際の重い処理は別サーバーで実行しつつ、エージェント側では進捗管理と状態遷移を制御できます。 📌 タイトル：Long Running Function ツール 🔗 URL： 🧩 概要 `LongRunningFunctionTool` は、長時間かかるタスクをエージェントワークフローに統合するためのクラスです。処理は4つのフェーズで進行します。開始フェーズでタスクを発行し、初期更新フェーズで進捗を通知し、続行/待機フェーズでクライアントが次のアクションを判断し、フレームワーク処理フェーズでエージェントランナーが一時停止を管理します。重要なのは、このクラスはオーケストレーションを管理するものであり、実際の長時間タスクの実行自体は行わないという点です。 🛠 使い方 ツール関数はステータスとチケットIDを含む辞書を返し、フレームワークがその状態を管理します。 ```python from adk import LongRunningFunctionTool def start_training(model_name: str, dataset: str) -> dict: """モデルトレーニングを開始する""" # 外部サーバーにリクエストを送信 ticket_id = external_api.start_job(model_name, dataset) return { "status": "in_progress", "ticket_id": ticket_id, "message": "トレーニングを開始しました" } tool = LongRunningFunctionTool(func=start_training) ``` エージェントランナーは返された状態に基づいて実行を一時停止し、クライアントが「続行」か「待機」かを決定します。実際の計算処理は別サーバーで行い、ツール関数はその進捗確認と状態報告のみを担当します。 🏗 本番システムへの組み込み方 ・実際の重い計算処理は専用のコンピュートサーバーで実行し、ツール関数はAPIコールのみ行う ・チケットIDを使った進捗追跡の仕組みを構築し、ポーリングまたはWebhookで状態を更新する ・タイムアウトとエラーハンドリングを適切に設定し、タスクの失敗を検知できるようにする ・クライアント側で待機/続行の判断ロジックを実装し、ユーザー体験を損なわないようにする 💡 ユースケース 🤖 機械学習モデルのトレーニングジョブの管理と進捗追跡 🎬 動画エンコードやレンダリングなど時間のかかるメディア処理 📦 大規模データのETLパイプラインの実行管理 🧪 長時間かかるテストスイートやベンチマークの実行と結果取得 ⚠️ 注意点 `LongRunningFunctionTool` はオーケストレーション（状態管理と進捗追跡）を管理するものであり、実際の長時間タスクを実行するものではありません。重い処理は必ず別のサーバーやサービスで実行してください。また、セッションの有効期限やメモリ管理にも注意が必要です。長時間のタスクではセッションが切断されるリスクがあるため、状態の永続化を検討してください。 ✨ 長時間タスクをエージェントワークフローにシームレスに統合できるこの機能は、実用的なAIシステム構築において非常に強力です。計算処理とオーケストレーションの責務を明確に分離しましょう。 #ADK# #AIAgent#

# OpenAI Agent SDKの便利だけど知られていない機能 🌍 ツールが多すぎてトークンを圧迫していませんか？必要なときだけツールを読み込む仕組みがあります。 `defer_loading` と `ToolSearchTool` を組み合わせれば、モデルが必要なツールを検索して動的にロードでき、トークン消費を大幅に削減できます。 📌 タイトル：Hosted tool search / tool_namespace / defer_loading 🔗 URL： 🧩 概要 `@function_tool(defer_loading=True)` を指定したツールは、初回のモデル呼び出し時にはツールリストに含まれません。代わりに `ToolSearchTool()` をエージェントに追加すると、モデルはまずツールを検索し、必要なものだけをロードして使用します。`tool_namespace` でツールをグループ化することも可能です。大量のツールを持つエージェントで、トークン使用量を最適化する強力な機能です。なお、この機能は `OpenAIResponsesModel` でのみ利用可能です。 🛠 使い方 ```python from agents import Agent, function_tool from agents.tool import ToolSearchTool @function_tool(defer_loading=True, tool_namespace="analytics") def run_report(report_type: str) -> str: return generate_report(report_type) @function_tool(defer_loading=True, tool_namespace="analytics") def export_csv(dataset: str) -> str: return create_csv(dataset) @function_tool(defer_loading=True, tool_namespace="admin") def manage_users(action: str) -> str: return user_management(action) agent = Agent( name="assistant", tools=[ ToolSearchTool(), # ツール検索を有効化 run_report, export_csv, manage_users, ], ) ``` 🏗 本番システムへの組み込み方 ・数十〜数百のツールを持つエージェントでトークンコストを抑える ・`tool_namespace` でツールを論理的にグループ化し、検索精度を向上させる ・頻繁に使うツールは `defer_loading=False`（デフォルト）のままにし、稀に使うツールだけ遅延ロードにする ・ツール追加時にプロンプトサイズを気にせずスケールできる 💡 ユースケース 🧰 多機能SaaSエージェントのツール管理 📊 分析・レポート系ツールのオンデマンドロード 🔧 管理系ツールの必要時のみ表示 🚀 ツール数のスケーラビリティ確保 ⚠️ 注意点 この機能は `OpenAIResponsesModel` でのみ利用可能です。他のモデルプロバイダーでは動作しません。また、遅延ロードされたツールは最初のターンでは使えないため、ユーザーの最初のリクエストに即座に対応する必要があるツールには向きません。 ✨ ツール検索で「必要なときに必要なツールだけ」をロードし、スマートなエージェントを実現しましょう。 #OpenAIAgentSDK# #AIAgent#